Real-time analytics with HBase (long version)，讲的很好，推荐 🔗 网页链接 //@zhh-2009 : 所以，我想以后那些更聪明的存储引擎最好能在应用建表时还能指定底层的数据结构，比如应用是写多读少的类型，用LSM-Tree更合适，读多写少用传统的B-Tree更合适。H2的MVStore存储引擎在这方面我看到一些影子了，单独使用MVStore时可以指定是用B-Tree还是R-Tree，不过它还没想到在建表时让用 展开全文 因为在实现索引，所以又重新研究了H2的B-Tree实现，对于Insert/Delete/Update很频繁的场景，都对同一棵B-Tree进行操作效率真的不如LSM-Tree好，总是先从Root找到某个Leaf，然后对存放记录的数组或List进行增加或删除元素。 //@Binos_ICT : 在没有对Phoenix下的表格进行优化的前提下，导入22279337 Row数据，共用43min,大约每秒可以达到8600条的导入速度。 Phoenix Github的位置(🔗 网页链接 Phoenix在Nosql上的SQL引擎 - 揭秘Phoenix在Nosql上实现SQL技术。 1）使用Antlr(www.antlr.org)实现了SQL语句的解析 原文地址： 🔗 网页链接 海量数据的在线应用在当前软硬件飞速发展的背景下，有非常广阔的发展前景，仍然有许许多多的新技术亟须实现。如果您既拥有丰富的理论知识，也有踏实的技术落地能力，希望让自己的代码为千千万万用户服务，诚请加入我们的团队 :) 求转发 有没有人试过这个开源库，storm-hbase？ 🔗 网页链接 //@何_登成 : 从Google的论文中学到一个名词——non-temporal operation(movntq)。普通的内存操作，操作的数据需要读入CPU Cache。而non-temporal memory access，内存操作可以绕过CPU的L2/L3 Cache，防止Cache被替换，对一次性读写的操作有优化效果。🔗 网页链接 🔗 网页链接 展开全文 High Scalability上介绍的一篇Google论文：Automated Locality Optimization Based on the Reuse Distance of String Operations 🔗 网页链接 介绍了Google对于字符串操作(memcpy...)的优化。.across all Google datacenter applications string operations take 2 of the top 10 spots 展开全文 