标签: scalability

对于目前只有很少（5-10）个设置但将来会有更多（最多100个）设置的应用程序，这将是更好的方法：

1. 每次引入新设置时向设置表添加新列
2. 将设置表作为键/值存储

考虑到应用程序可能有数百万个实例（它们都在同一个数据库上运行并使用同一个表进行设置），数据库可能被分片。DB 是关系型的，即 MySQL 或 T-SQL。

作为开发人员，我更喜欢第二个变体，因此我可以在不更改数据库架构的情况下扩展应用程序并随意添加/删除设置。据我了解，如果索引聚集在应用程序实例上，那么在单个表中拥有几百万条记录应该不是问题。有什么我不知道的缺点吗？

那么第一个变体呢？有什么大的好处吗？那么列数呢：表可以包含的列数是否有任何理论限制？如果我有一个包含 1000 (10 000, 1000 000) 列的表会发生什么？那会不会很慢？

我的数据库是 SQL Server 2008，我想将系统扩展 5 倍（将来可能会更多）。

该系统目前有 95% 的读取和 5% 的前端写入。并使用 ETL 从后端批量加载实际数据。

我查看了类似的选项

1. 使用共享数据库进行扩展（使用 SAN）
2. SODA（新的缓存机制）
3. SQL Server 2008 R2 中的群集

但 all 要么只允许读取或复制现有数据。

有人能指出我正确的方向吗（复制数据将是我最后的选择）。

谢谢 JC

谢谢大家的建议。

看起来我现在只能增加硬件并获得更好的性能。

SAN 设置将成为更多的管理工作，因为数据加载的更新每天至少发生一次，我们每次都需要关闭 SAN 上的服务器。前端也有一些更新。

我计划做的另一件事是根据区域将数据划分到两台服务器上，这会将每台服务器上的负载减少到几乎一半。

我们有使用Golang、PostgreSQL和sqlx（适配器、连接池）的Web 应用程序，每个请求需要 1 到 8 个查询，有时 1 个事务需要 5-8 个选择和 5-8 个插入查询。

我们已经将 PostgreSQL 设置max_connections为 1024，然后是 4096，但是它开始交换，所以我们将它们减少到 64（这是交换前的限制）。

我们的 RAM 是 2GB，我们将 PostgreSQL 配置working_mem为 16MB、temp_buffers8MB、shared_buffers800MB、effective_cache_size 1536MB（这个配置根本不交换）。

每天 00:00 到 02:35 每秒大约有 18 个请求，每秒大约有 8 个错误，此时每小时只有 10 个事务成功，其他事务失败，错误消息如下：

• 剩余的连接槽保留用于非复制超级用户连接
• 已经有太多客户了

除了缓存只读页面（因为页面每分钟可以更新10次左右）或升级机器之外，如何克服这个问题？

我正在考虑扩大规模而不是扩大规模。因此，我很想知道将 MySQL 内存存储引擎用于 500+ GB 的数据库是否可行，因为有一台服务器，具有这种内存？我应该提到对表的查询主要是临时查询。

我相信我发现会出现的一个问题是对 MEMORY 表的查询可能会导致创建临时表。临时表在转换为 MyISAM 表之前有一个硬性限制，即最多使用4 GB的 RAM。这当然会完全杀死性能。临时表的内存限制可以通过将tempdir设置为 ramdisk 来解决。

您还预见到哪些其他类型的问题？

最近我遇到了 Nosql 数据库概念，虽然我学会了如何使用它以及为什么使用它，但我没有得到正确答案，它支持什么规模的项目？

它是否支持更大的应用程序，这些应用程序通常有很多统计用途，比如谷歌分析（示例）？他们的可靠数据或应用程序是否已经在诸如 couchbase 等数据库上运行？

为了扩展 PostgreSQL 流复制从属设备上的读取流量，我希望能够对请求进行负载平衡。Postgres 文档建议使用 pgPool 和 pgBouncer 之类的工具，但我想知道在 postgres 读取从站前面使用 TCP 负载均衡器（如 HAProxy 或 AWS Elastic Load Balancer）是否有问题（原则上）。

负载均衡器充当需要由客户端发出的读取请求的单个读取端点。一个显着的优势是当读取从属服务器关闭时读取请求不会受到影响，因为负载均衡器中的其他服务器可以接收负载。

目前我们有一个大小为 4 TB 的数据库。我们希望将其放入 2014 年可用性组以扩展读取。该数据库中的数据发生了很大变化。

我有以下问题：

1. 这个大小是否适合可用性组（我们希望有 2-3 个副本）？
2. 如果网络中断 1 小时，我们可以多快同步副本？
3. 在使用可用性组之前，你们有什么我应该遵循的考虑吗？

有没有人有使用ScaleArc 的经验？

我的 CTO 询问了我对此的看法，但我没有看到有关现实世界体验的任何信息。

有没有可用的工具可以使用MySQL通用日志创建的日志文件进行压力测试？在谷歌上进行了大量搜索后，我发现很少有压力测试工具只使用一些基准进行压力测试。一种解决方案是使用 Apache JMeter，但它不会从 MySQL 日志文件创建测试计划，并且为我拥有的所有查询创建自定义测试计划太耗时了。
或者是否有至少可以从 MySQL 日志创建 .sql 文件的工具？

我正在寻找实现以下目标的数据库：

1. 完全酸性。
2. 与连接相关。
3. 有交易。
4. 允许管理员指定分片规则（例如：来自欧洲的用户应该位于欧洲数据中心）。
5. 最苛刻的要求：在网络分区时，就像两个数据中心相互断开连接一样，每个数据中心都应该能够读取和写入其中的节点。基本上，我愿意为了分区容错而牺牲部分可用性。可悲的是，大多数解决方案都会在出现裂脑的情况下停止所有读取和写入。（因此，优先于可用性而不是分区容错性）

我更喜欢开源解决方案，但也愿意考虑专有解决方案。

是不是可以通过虚拟化来扩展数据库服务器，就像永远一样？我喜欢将大部分工作负载保留在数据库服务器上，因为它优化了查询，并且该架构减少了 db 服务器和 web 服务器之间的带宽使用。有什么理由我不应该在可扩展性方面这样做吗？