高并发，高写入DB的基础结构

17

我的要求是：

3000个连接
70-85％写入与读取

目前，我们正在通过700个连接最大化高CPU超大型实例。所有8个内核均已最大化。我们认为这是并发连接数，因为内存很好。写入本身非常简单（验证很慢）。要扩展到3000，我们需要转到多台服务器，当前选项为：

MySQL分片
MongoDB集群
卡桑德拉
Hadoop和MySQL（Hadoop缓存，一次转储到MySQL）
MongoDB和MySQL（代替Hadoop，我们使用mongo进行缓存）

要处理此数量的连接，有几个问题：

MySQL分片可以处理并发连接吗？
任何一个主服务器都可以处理这些并发连接，还是像Mongo这样的多头设备是更好的选择？

如果不能很好地描述我的问题，我深表歉意。请问问题。

— 贾斯汀
source

4

工作量是多少？不做任何工作的连接不占用内存，却不占用CPU，受写限制的应用程序也占用很少的CPU，因为它一直在等待I / O。如果您的CPU达到极限，则意味着您正在执行某种计算。这就是瓶颈所在，而不是连接本身的数量，也不是写入活动的瓶颈。

— Gaius

谢谢回复。令人遗憾的是，随着您获得更多的连接，一切都会变得繁重。1-> 100-> 500->1000。在3000个并发连接中，mysqlslap会自行杀死。通过这个简单的测试，CPU和I / O在700个连接处开始消失。这是我们所看到的，但是更糟糕的是，因为我们有更多的数据。

— 贾斯汀

5

如果您将MySQL用作主数据库，则可能要考虑通过MySQL复制使用星形拓扑。

现在，在对MySQL复制说UGHHH，ROFL和OMG之前，请听我说。

星型拓扑允许您写入一个数据库服务器（称为分发Mster [DM]），并将SQL命令发送到多个数据库服务器。您如何设置这样的数据库基础架构？

这是说明

您有5个数据库服务器（服务器A，B，C，D，E）

服务器A

在MySQL复制设置中，它将是Master
扮演DM的特殊角色
服务器B，C，D，E的主服务器
所有表都使用存储引擎BLACKHOLE（/ dev / null）
仅存储二进制日志
裸机
好处
- 由于DM上的所有表都使用BLACKHOLE，因此写入速度非常快
- 网络延迟不是问题，因为读取是数据库活动的15-30％
- 严格从DM更新所有从站

服务器B，C，D，E

A的奴隶
为繁重的SELECT服务奠定基础
服务器可以是虚拟或裸机
对于所有其用户表使用存储引擎InnoDB的服务器
- 它可以作为热备份数据库服务器
- 可以对其进行非侵入式备份
对于其用户表使用存储引擎MyISAM的所有服务器
- 设置只读选项
- 表可以重做其行格式以加快读取速度

我以前对此写过文章

使MySQL复制保持最佳状态

使用MySQL 5.5
使用半同步复制
调整InnoDB以使用更多CPU

— 罗兰多·MySQLDBA
source

2

MySQL Cluster可能是另一种分片方法。在这里检查帖子。

我也是Cassandra的忠实拥护者，但这很大程度上取决于您的数据模型和要执行的查询。卡桑德拉（Cassandra）擅长快速写入，因为它们在磁盘上始终是顺序的。

— gsb
source

2

如果您打算采用多头方式（如果您确实需要3K主动连接，可能需要这样做），我可能会看Riak或Cassandra。这实际上取决于您的应用程序对它们的适应程度如何，但是从您的描述来看，我认为它会适合Riak之类的东西。

也就是说，如果您可以找到一种很好的方法来分割数据，并且可以最大限度地减少对交叉分片的需求，那么分片的方法似乎是可行的。我会远离mysql中的任何ring / star / mmm东西，并坚持使用直接分片。实际上，如果您愿意使用Postgres，则可以在诸如heroku之类的模型上使用架构轻松地进行原型设计，然后在数据库开始扩展单个节点时分叉并拆分数据库。

哦，虽然我认为您可以尝试纵向扩展此类内容（单个节点处理所有3K conns），但我认为您无法在云中进行扩展。

— xzilla
source

1

如果您的特定应用程序是一个选项，也许您可以使用某种异步方式将数据写入数据库（工作队列，批处理插入...）和/或通过使用一些代理来转移数据库中的许多客户端连接。

使用分片，您通常可以很好地扩展（2x db-servers == 2x连接），但这在很大程度上取决于数据集的性质以及如何在各个分片之间进行拆分。

1

我个人更喜欢MongoDB，因为它易于管理，可扩展性和一般易用性。另外，除非我实际上需要RDBMS，否则我将使用no-SQL。

话虽如此，请选择最适合您的应用程序的数据库。如果您需要事务处理，或者如果没有Joins不能设计您的应用程序（或者简单地说，对它们来说更有意义），请使用RDBMS（MySQL，PostGres等）

虽然我个人更喜欢MongoDB，但MySQL无法扩展或无法处理高事务率的想法纯属错误。Facebook工程团队（以及其中的MySQL团队）对此进行了详细介绍。另请查看Etsy Ops团队博客；他们也喜欢MySQL。

最后，我不会将MongoDB用于MySQL缓存。为此使用Memcached。

Redis还是一个RAM内键值存储，非常适合处理某些用例。blog.agoragames.com上有一些博客条目描述了一些用例。

如果您正在考虑使用No-SQL，还应该签出CouchDB。请注意，它需要定期维护才能降低磁盘利用率。（它为磁盘实用程序交换了速度和便利性...）

最后，容量计划不容易预测。您需要在尽可能现实的条件下进行测试，并准备根据所看到的内容进行补救。可悲的是，“计算机科学”与科学一样多。

— 沃尔多
source