标签: scalability

为 ~10B 对象设计对象存储并使用 mySQL 存储元数据。我们知道我们需要分片，并且正在寻找通用的启发式方法来扩展。希望得到指点，并了解你们都使用过的粗略计算

我有一个包含十亿级表的 Postgres 数据库。所以任何聚合函数，例如count() 和avg()，以及“order by random()”都是非常耗时的。Postgres 有 pg_catalog，其中包含许多描述数据库的有用统计信息（例如视图 pg_stats 中的直方图箱）。有没有办法利用 pg_catalog 中的统计信息来估计 Postgres 表中数字列的平均值和中位数？

鉴于 NoSQL 数据库旨在通过投入更多服务器来支持水平可扩展性，是否有任何数据库旨在完全无需持久磁盘存储？

我正在寻找一个需要水平可扩展性但也需要加密任何静态数据的应用程序。这最终可能意味着将大量数据从 NoSQL 数据库提取到内存缓存（如 memcached）中。这让我想知道：是否有任何单一产品具有 NoSQL 数据库的规模和容错特性，但仅在内存中运行？

MySql 数据库即服务：

1. 亚马逊
2. 泽润

另一个例如。PostgreSQL 数据库即服务。您可以在此处获取类似产品的列表。

有没有人详细了解这些 DbaaS 的性能、可靠性和可扩展性？阅读有关这些产品的文献会使它们听起来好得令人难以置信。我内心的愤世嫉俗感告诉我要质疑这些说法。

我知道有可能拥有一个包含许多表/数据库的单个数据库服务器，并且您可以将其中一些表/数据库分离到单独的磁盘中。假设您有 5 个表/数据库和 5 个驱动器。因此，您将每个表/数据库附加到不同的驱动器。从而增加 IO 和其他一切。

那个技术叫什么？

我认为如果您尝试分离数据库，您只需将不同的驱动器安装到不同数据库的不同文件夹，但是如果您想将表分离到不同的驱动器（每个表在不同的磁盘中）怎么办

我们有一个关于 Server Fault 的问题，提出了一个有趣的问题：
鉴于 Postgres 9.2 可扩展性改进中的可扩展性改进，使用连接池机制来避免与数据库建立额外连接的开销更好，还是连接提高读取性能的开销值得吗？

将它具体与我的环境相关联：我们有一个以数据库为支持且以读取为中心的 Web 应用程序，我们目前在 Postgres 8.4 上运行。

我们的重新实现将于明年启动，同时升级到 9.2，并为每个 Apache 工作进程提供自己与数据库的连接（因此，它自己的 Postgres 后端会在 Apache 工作人员的生命周期内保留）。
根据我们所看到的，这似乎是连接到数据库的开销和让更多工作人员处理读取负载之间的良好平衡，尽管我们还没有进行任何实质性的基准测试来确认这一点。

该实现看起来是否合理？鉴于最近的可扩展性改进，我们是否应该考虑其他选项/连接池机制？

我有一个 Postgres 数据库，它已经增长到无法将所有内容存储在单个数据库节点上的大小。Customer我的架构中有一个表，其中每一行代表一个（惊喜！）客户。我的数据库中的每个其他表都是这个客户表上的外键，我想沿着客户范围对我的数据库进行分片。例如，我希望id1 - 100 的客户转到数据库节点 A，101 - 200 转到数据库节点 B，依此类推。

我找到了有关表分区的信息，但我发现很少有其他内容可以向我展示如何在 Postgres 中启用数据库分区。

在 Postgres 中分片数据库有哪些选择？如果无法进行分片，我的替代方案是什么？

我已经在stackoverflow上发布了这个问题，但我想我可能会在这里得到更好的答案。
我有一个表存储用户发生的数百万个事件：

                                       Table "public.events"
   Column   |           Type           |                         Modifiers                         
------------+--------------------------+-----------------------------------------------------------
 event_id   | integer                  | not null default nextval('events_event_id_seq'::regclass)
 user_id    | bigint                   | 
 event_type | integer                  | 
 ts         | timestamp with time zone | 

event_type 有 5 个不同的值、数百万用户以及每个用户每个 event_type 的不同事件数，通常范围为 1 到 50。

数据样本：

+-----------+----------+-------------+----------------------------+
| event_id  | user_id  | event_type  |         timestamp          |
+-----------+----------+-------------+----------------------------+
|        1  |       1  |          1  | January, 01 2015 00:00:00  |
|        2  |       1  |          1  | January, 10 2015 00:00:00  | …

我有一个 SQL Server 2014 数据库，其中包含 100 多个表，在一年中的增长率为 5%。读书多，写作少。

该数据库将通过另一组 20 多个表进行扩展，这些表定期（每季度）在一夜之间增长，几乎与整个数据库其余部分的总和一样多。

这些表在处理结束时在几个小时内完全清空。该数据在这些表是相当消耗，但需要在同一个数据库，其余为参照完整性。

对于一些示例数字，假设第一个 DB 是 20GB，表的子集增长到 15GB，然后被清空。因此，数据的实际大小在几天内在 20 到 35 GB 之间波动。

• 在规划这个系统时我可以做些什么来帮助解释这种波动？
• 这是文件组发挥作用的地方吗？
• 我将这组表移动到它们自己的文件组有什么优势/问题？

就性能而言，是只使用几个有很多行的表还是很多只有几行的表比较合适？就我而言，我有一些单独保存数据的组。是为每个组创建一个新表还是将组的所有信息保留在一个表中（这将变得非常非常大）并有一列标识它属于哪个组更好？哪个版本在可扩展性方面会更好？我正在使用 PHP 来访问数据，并且每次页面加载时只需要获取一组或两组的数据。我主要关心存储大量数据时系统的速度。谢谢。