7

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

我的设置包括以下内容：

用户 ---> Web 应用程序 --> 消息队列 --> 解析器 --> 数据库？

我应该提到，解析器目前可以使用 COPY 解析/填充大约 18750 条记录/秒，因此在我们开始添加更多解析器之前，我们在这方面受到限制——这对我来说现在不是一个大问题。

我有一个系统，需要能够尽可能快地批量上传尽可能多的记录。这个相同的系统（或者它可以根据您的处理方式而有所不同）应该能够响应分析类型的查询，例如：

wonq = "从玩家 = '@player' 和 " +
       "(type = 'award' or type = 'return') and hand = hand_num"
lostq = "从 player = 'player' 和 " + 的操作中选择 sum(amount)
        “输入！='award'并输入！='return'和hand = hand_num”

.....10-15 千次（每个用户），因为它们被锁定到另一个表。不用说，我们现在将这些结果分页为 10/页。

我查看了以下内容：（假设这些都在同一台服务器上）

  • mysql (reg. run of the mill rdbms)——能够进入 15-20,000 个请求/秒的范围；在当前条件下，如果我们尝试扩展它，我们每次需要扩展时都需要一个单独的主机/数据库——这是不可行的

  • couchdb（面向文档的数据库）——没有打破 700 个请求/秒；我真的希望这能拯救我们的屁股——不是机会！

  • vertica（面向列的数据库）——达到 60000 个请求/秒，封闭源代码，非常昂贵；这仍然是一个选择，但我个人根本不喜欢它

  • tokyocabinet（基于哈希的数据库）——目前的重量为 45,000 次插入/秒和 66,000 次选择/秒；昨天当我写这篇文章时，我使用了一个基于 FFI 的适配器，它的性能大约为 5555 个请求/秒；这是迄今为止我见过的最快最棒的数据库！

  • 兵马俑——（vm集群）目前正在与jmaglev一起评估它（不能等到maglev本身出来）——这是最慢的！

也许我只是错误地解决了这个问题，但我总是听说 RDBMS 非常慢 - 那么我听说过的这些超快速系统在哪里？

测试条件::

只是让人们知道我在我的开发盒上的规格是：

双 3.2ghz 英特尔，1 gig ram

Mysql mysql.cnf 编辑为：

key_buffer = 400M # 是 16M
innodb_log_file_size = 100M # 之前不存在
innodb_buffer_pool_size = 200M # 之前不存在

更新::

事实证明，terracotta 可能在我们的应用程序结构中占有一席之地，但它不会很快替换我们的数据库，因为它的速度很糟糕，而且它的堆利用率很糟糕。

另一方面，我很高兴看到 tokyocabinet 的 NON-FFI ruby​​ 库（意思是 tyrant/cabinet）超级快，现在它是第一名。

4

8 回答 8

6

对于疯狂的大可扩展性，您需要关注两件事：

  • 分片：将您的数据集分成不重叠的组。有一种从请求映射到服务器的简单、快速的方法。（以 af 开头的播放器，服务器 1；gq，服务器 2……等等……）
  • 缓存：使用 Memcache 来记住一些非常常见的选择查询的输出，因此您不必经常访问磁盘。
于 2009-02-17T23:12:35.833 回答
1

好吧，游戏中的大玩家是甲骨文，但那是一大笔钱。

如果您想便宜，那么您将不得不以不同的方式支付价格：

  • 通过跨多个实例对数据库进行分区并分配负载。
  • 可能缓存结果，因此减少了实际的数据库访问。
于 2009-02-17T23:17:27.990 回答
0

你试过postgresql吗？它应该比mysql快。但无论如何，您需要平衡多个服务器（拆分数据库）的负载。您可以拥有多个数据库（例如，每个客户端），然后一个集中式数据库将与那些小型数据库同步...

于 2009-02-18T22:12:59.913 回答
0

在写入繁重的应用程序中快速持久地存储数据的典型方法是使用仅附加日志。如果正确部署日志文件在其自己的旋转磁盘上，则每次写入/追加操作的磁盘寻道时间最小化。

可以在每次写入后更新元数据以了解某些主键的偏移量。

有一个mysql存储引擎可以做到这一点是你要使用mysql。另一种选择是新的 nosql 数据库之一，例如fleetdb。

您是否也尝试过使用SSD？

有很多选择可以解决这个问题，但它们可能需要一些体力劳动。

于 2010-01-08T13:33:57.240 回答
0

用户 ---> Web 应用程序 --> 消息队列 --> 解析器 --> 数据库？

你需要消息队列做什么？这些通常是一个很大的性能问题。

于 2009-02-17T23:25:16.503 回答
0

你试过redis吗？他们承诺 110000 SETs/秒、81000 GETs/秒的速度。这是一个支持列表和集合的高级键值数据库。

于 2009-09-22T22:23:56.517 回答
0

正如 ojrac 所说，分片和缓存。

另一种选择是退后一步，想办法用更少的查询来完成工作！从您提供的少量信息中，我不禁想到“一定有更好的方法”。从您提供的一些汇总表（带有可选缓存）的示例中可能会很容易获胜。

Hypertable 等为某些数据访问模式提供了更好的性能，但您的听起来非常适合典型的数据库。

是的，CouchDB 的速度慢得令人失望。

于 2009-02-18T00:21:10.630 回答
0

我怀疑任何系统都会为您提供所需的开箱即用性能。您可能会开始在您所在的机器上达到硬限制（几乎任何写入密集型数据库都会很快达到 I/O 限制）。可能需要进行一些分析，但磁盘几乎总是瓶颈。更多的 RAM 会有所帮助，使用固态磁盘也是如此。

但是，无论您使用哪个实际数据库，您都可能需要某种类型的集群。您可以对数据本身进行分片，或者使用 MySQL，设置 read-slaves 将负载分散到节点上，并为您提供所需的吞吐量。

另外：MongoDB 很棒。也许值得一瞧。

于 2009-09-22T22:41:59.110 回答