将数据库构建为可扩展的最佳实践答案

【问题标题】：Best practices to structure a database to be scaling-ready将数据库构建为可扩展的最佳实践
【发布时间】：2012-01-19 05:09:25
【问题描述】：

我知道这是一个非常笼统和主观的问题，所以如果它不符合 StackOverflow 网络礼节，请随时投票关闭它。但对我来说，值得尝试 ;)

从现在开始，我再也没有构建过高流量的应用程序，所以我不知道（除了一些在网络上阅读的内容）有关扩展实践的信息。

如何设计一个数据库，在需要扩展时，我不必重构数据库结构或应用程序代码？

我知道开发（和优化）应该循序渐进，在瓶颈发生时对其进行优化，并且当您不知道您将拥有多少用户以及如何使用时，几乎不可能设计出完美的结构他们使用数据库（例如读/写比率），我只是在寻找一个好的基础。

使结构几乎可以使用partitioning 和sharding 进行缩放的最佳做法是什么？必须绝对避免使用hacks？

编辑关于我的应用程序的一些细节：

【问题讨论】：

我为您在设计上的超前思考而不是仅仅潜入并希望获得最好的结果而鼓掌。然而，我能给你的最好的建议是，当你第一次认为你需要分片或分区时：不要！真正查看您的数据库使用模式，您可能会发现这是对数据库的不良使用，而不是需要“扩展”。太多次，我看到人们试图通过分片来扩展糟糕的代码。它来自“把硬件扔到问题上”的想法。现在他们有更多的硬件需要维护，一个共享的基础设施，剩下的代码仍然很糟糕。
@MatthewWood 我已经完成了一个“最好的祝愿”的项目构建，它应该是一个“个人”项目，但后来成长为中小型......数据库（和代码）是维护的噩梦；）我不想犯同样的错误两次；）我同意你的观点，大部分优化应该首先出现在代码中，硬件扩展是最后一次尝试

【解决方案1】：

这个问题很笼统，但这里有一些提示：

不要在应用程序代码中使用任何会话变量（pg_backend_pid()、inet_client_addr()）或每个会话控制（SET ROLE、SET SESSION）。
不要在应用程序代码中使用显式事务控制（BEGIN/COMMIT/SET TRANSACTION）。所有此类逻辑都应包含在UDFs 中。这启用了 stateless 语句模式池，可实现最快的 DB 池。（请参阅pgbouncer docs 和pg wiki 了解更多信息）
将所有 AppDb 通信封装在定义良好的 UDF 数据库 API 中 - 这将允许您使用 PL/Proxy。如果对所有 SELECT 执行此操作太难，请至少对所有数据写入（INSERT/UPDATE/DELETE）执行此操作。示例：您需要 SELECT create_user('Joe')，而不是 INSERT INTO users(name) VALUES('Joe')。
检查您的数据库架构 - 是否容易分离属于给定用户的所有数据？（很可能这将是分区键）。剩下的就是需要复制到所有节点的通用共享数据。
在需要之前考虑缓存。什么是缓存密钥？什么是缓存超时？你会使用 memcached 吗？

【讨论】：