两种常见的查询：产品搜索 和 历史交易记录查询 都需要比较长的响应时间。
我知道一些解决方案，但我还没遇到过真实的案例。所以问下本版的牛人，有没有相应的知识。
就我浅薄的阅历来说，有效的解决办法有四个：
1.做好关系数据库相关的优化，比如SQL的优化，建索引，分区，读写分库等等。但这些都无法永远伸缩，总有一天会碰到天花板。
2.建立专门的索引库（未必是数据库），每天晚上批量地生成索引数据，或者改变业务数据时立即更新索引数据。
3.使用专门的OLAP数据库来提供查询。但是，在我印象中这种方案需要引入比较重量级的 数据转换/传输 机制，而且数据的实时性很难保证。
4.纯内存数据库。 好像校内网还是豆瓣网正在用这个东西。
大家有没有真实的案例？比如淘宝、Amazon是怎么弄的？
产品搜索的话可以考虑用memcached
历史交易查询，楒有两种方法
一种是按时间建分表，查询按时间查询，交易完成后，移入历史交易表
第二的话可以考虑用文件块来存储用户数据，数据库只记录用户与文件索引块的关系
可以考虑一下
你说的是key-value DB?
我觉得按时间建立分表比较可行。
如果想性能高的话 就用文件块啊
直接读取文件