(怎么能/应该怎么做)我实现了一个可以扩展到数万个请求/秒的数据库？

Question

通过数万个请求/秒,我希望看到60,000 - > +90,000个请求/秒.

我的设置包括以下内容:

用户--->网络应用 - >消息队列 - >解析器 - >数据库？

我应该提一下,解析器当前可以使用COPY解析/填充大约18750条记录/秒,所以我们在这方面受到限制,直到我们开始添加更多解析器 - 这对我来说不是一个大问题.

我有一个系统,需要能够尽可能快地批量上传尽可能多的记录.同一个系统(或者根据你如何处理它可能会有所不同)应该能够响应分析类型查询,例如:

wonq = "select sum(amount) from actions where player = '@player' and " +
       "(type = 'award' or type = 'return') and hand = hand_num"
lostq = "select sum(amount) from actions where player = 'player' and " +
        "type != 'award' and type != 'return' and hand = hand_num"

..... 10-15000次(PER USER),因为他们被锁定到另一张桌子.毋庸置疑,我们暂时将这些结果分页为10页/页.

我看了下面的内容:(假设这些都在同一台服务器上)

• mysql(运行rdbms的运行) - 能够进入15-20万个请求/秒范围; 在当前条件下,如果我们试图扩展这一点,我们需要一个单独的主机/数据库每次我们需要扩展 - 这是不可行的

• couchdb(面向文档的数据库) - 没有突破700个请求/秒; 我真的希望这会拯救我们的屁股 - 不是机会!

• vertica(柱状导向数据库) - 正在达到60000请求/秒,封闭源,非常昂贵; 这仍然是一个选择,但我个人根本不喜欢它

• tokyocabinet(基于散列的数据库) - 目前的重量为45,000次插入/秒和66,000次/秒; 昨天,当我写这篇文章的时候,我使用的是基于FFI的适配器,每秒执行5555次请求; 这是迄今为止我见过的最快最棒的数据库!!

• 兵马俑 - (vm集群)目前正在与jmaglev一起评估(不能等到磁悬浮本身出来) - 这是最慢的!

也许我只是在接近这个问题,但我总是听说RDBMS一切都很慢 - 所以我听说过这些超快系统在哪里？

测试条件 ::

只是这样ppl知道我的开发盒上的规格是:

dual 3.2ghz intel, 1 gig ram

Mysql mysql.cnf的编辑是:

key_buffer = 400M               # was 16M
innodb_log_file_size = 100M     # non existent before
innodb_buffer_pool_size = 200M  # non existent before

更新 ::

事实证明,兵马俑可能在我们的应用程序结构中占有一席之地但它不会很快取代我们的数据库,因为它的速度非常糟糕并且它的堆利用率很低.

另一方面,我很高兴看到tokyocabinet的NON-FFI红宝石图书馆(意思是暴君/内阁)超级快,现在是第一名.

Answer 1

对于疯狂的大扩展性,您需要关注两件事:

• 分片:将数据集拆分为不重叠的组.有一种简单,快速的方法从请求映射到服务器.(播放器以af开头,服务器1; gq,服务器2 ......等...)
• 缓存:使用Memcache记住一些非常常见的选择查询的输出,因此您不必经常访问磁盘.