标签: scalability

nosql DBMS 的一大优点是它们可以更轻松地进行集群。据称，使用 NoSQL，您可以创建数百台廉价的机器来存储不同的数据并一次查询所有数据。

我的问题是，为什么关系型 DBMS 不能像 mysql 或 sql server 那样做？是因为供应商还没有想出一种技术方法来使用他们现有的产品来做到这一点，还是关系模型存在一些问题阻止了这种做法的可行性？NoSQL 存储和访问数据（键/值、文档等）的方式有什么好处，使聚类更容易（如果这是真的）？

我正在建立一个 SaaS 系统，我们计划在其中为每个客户提供自己的数据库。系统已经设置好，如果负载变得太大，我们可以轻松地扩展到其他服务器；我们希望拥有数千甚至数万名客户。

问题

• 在一个 SQL Server 上可以/应该拥有的微数据库数量是否有任何实际限制？
• 它会影响服务器的性能吗？
• 是拥有 10,000 个 100 MB 的数据库还是一个 1 TB 的数据库更好？

附加信息

当我说“微数据库”时，我的意思并不是“微”；我的意思是我们的目标是成千上万的客户，所以每个单独的数据库只会占总数据存储量的千分之一或更少。实际上，每个数据库都在 100MB 左右，具体取决于它的使用量。

使用 10,000 个数据库的主要原因是为了可扩展性。事实上，系统的 V1 有一个数据库，当数据库在负载下紧张时，我们有一些不舒服的时刻。

它使 CPU、内存、I/O 变得紧张 - 以上所有。尽管我们解决了这些问题，但它们让我们意识到，在某些时候，即使使用世界上最好的索引，如果我们像我们希望的那样成功，我们根本无法将所有数据放在一个大喇叭中' 数据库。因此，对于 V2，我们进行了分片，因此我们可以在多个数据库服务器之间分配负载。

去年我一直在开发这个分片解决方案。每台服务器一个许可证，但无论如何，因为我们在 Azure 上使用虚拟机，所以已经解决了这个问题。现在出现这个问题的原因是，以前我们只向大型机构提供服务，并自己建立每个机构。我们的下一个业务是自助服务模式，任何拥有浏览器的人都可以注册并创建自己的数据库。他们的数据库将比大型机构小得多，数量也多得多。

我们尝试了Azure SQL 数据库弹性池。性能非常令人失望，因此我们切换回常规 VM。

我听说非分片关系数据库（如 MySQL 或 PostgreSQL）的性能“突破”超过 10 TB。

我怀疑这样的限制确实存在，因为人们不会想出 Netezza、Greenplum 或 Vertica 等，但是我想问这里是否有人参考了任何研究论文或正式案例研究，其中量化了这些限制。

在数据库上下文中，我发现水平可扩展性是 NOSQL 数据库的优势之一。这个词是什么意思？

• 维基百科上的 CouchDB
• 维基百科上的 NoSQL

与垂直缩放相比如何？

我有多个用于 Web 应用程序的 PostgreSQL 服务器。通常在热备模式（异步流复制）下一个主多从。

我使用 PGBouncer 进行连接池：安装在每个 PG 服务器（端口 6432）上的一个实例连接到本地主机上的数据库。我使用事务池模式。

为了在从站上平衡我的只读连接，我使用 HAProxy (v1.5) 和 conf 或多或少像这样：

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

因此，我的 Web 应用程序连接到 haproxy（端口 10001），即在每个 PG 从站上配置的多个 pgbouncer 上的负载平衡连接。

这是我当前架构的表示图：

这很有效，但我意识到有些人的实现方式完全不同：Web 应用程序连接到单个 PGBouncer 实例，该实例连接到 HAproxy，它在多个 PG 服务器上进行负载平衡：

最好的方法是什么？第一个（我现在的）还是第二个？一种解决方案相对于另一种解决方案有什么优势吗？

谢谢

人们经常重复说，大数据问题是关系数据库无法扩展以处理现在正在创建的海量数据。

但是，Hadoop 等大数据解决方案不受哪些可扩展性限制？为什么 Oracle RAC 或 MySQL 分片或像 Teradata（等）这样的 MPP RDBMS 不能实现这些壮举？

我对技术限制感兴趣 - 我知道集群 RDBMS 的财务成本可能令人望而却步。

Postgres 如何触发机制规模？

我们有一个大型的 PostgreSQL 安装，我们正在尝试使用日志表和 TRIGGER(s) 来实现一个基于事件的系统。

基本上，我们希望为每个我们希望收到更新/插入/删除操作通知的表创建一个 TRIGGER。一旦触发此触发器，它将执行一个函数，该函数将简单地将一个新行（对事件进行编码）附加到一个日志表中，然后我们将从外部服务轮询该日志表。

在全面使用 Postgres TRIGGER(s) 之前，我们想知道它们是如何扩展的：我们可以在单个 Postgres 安装上创建多少个触发器？它们会影响查询性能吗？有没有人试过这个？

在某些情况下，需要非常大的查询将多个表与其中的子选择语句连接在一起以产生所需的结果。

我的问题是，我们是否应该考虑使用多个较小的查询，并通过多次调用查询数据库将逻辑操作带入应用程序层，还是最好一次性完成所有操作？
例如，考虑以下查询：

SELECT *
FROM   `users`
WHERE  `user_id` IN (SELECT f2.`friend_user_id`
                     FROM   `friends` AS f1
                            INNER JOIN `friends` AS f2
                              ON f1.`friend_user_id` = f2.`user_id`
                     WHERE  f2.`is_page` = 0
                            AND f1.`user_id` = "%1$d"
                            AND f2.`friend_user_id` != "%1$d"
                            AND f2.`friend_user_id` NOT IN (SELECT `friend_user_id`
                                                            FROM   `friends`
                                                            WHERE  `user_id` = "%1$d"))
       AND `user_id` NOT IN (SELECT `user_id`
                             FROM   `friend_requests`
                             WHERE  `friend_user_id` = "%1$d")
       AND `user_image` IS NOT NULL
ORDER  BY RAND() 
LIMIT %2$d

最好的方法是什么？

我有一个电子邮件应用程序，它将被要求在每个页面加载时将给定用户的新消息数量传送到 UI。我在数据库级别上测试了一些变化，但所有内容都由存储的 proc 调用抽象。

我试图猛击数据库以查看断点（每秒请求数）是什么。

简而言之，我有一个表，比如这个 userId、newMsgCount，在 userId 上有一个聚集索引。SQL 应该能够每秒处理成百上千个这样的响应。我认为落后者是我的 .NET 应用程序。

我怎样才能使这个测试成为一个很好的测试来实现基于 SQL 性能的测试结果？

有没有一个工具，我可以给它一个存储的过程名称和参数，以便它打我的数据库？

我想看看数据库是否可以返回分钟。每秒 250 个响应。

鉴于用例：

• 租户数据不应串扰，一个租户不需要另一个租户的数据。
• 每个租户都可能拥有大量的历史数据。
• SQL Server 托管在 AWS EC2 实例中。
• 每个租户在地理上都很遥远。
• 有意向使用第三方可视化工具，如 PowerBI Embedded
• 数据量预计会随着时间的推移而增长
• 系统的成本受到限制。
• 解决方案必须是可维护的，无需 24/7 全天候生产 DBA
• 该解决方案应该能够水平扩展。
• 租户总数少于50人

推荐的架构是什么，此用例是否有任何参考实现？我相信很多人可能已经在企业软件开发中遇到过这个问题。

我认为这与在多租户数据库架构中处理越来越多的租户不同。该问题中提到的用例涉及更多租户，这与拥有很少 (50) 个大租户有很大不同。提到的架构可能是这里的一个解决方案，这也是我想了解的更多信息。