我想知道在使用大型数据库时会出现哪些具体问题/解决方案/建议/最佳实践[不要因为这个词而惩罚我]。
在巨大的情况下，我暗示数据库，其中包含具有数百万行的表和/或具有 PB 级数据的数据库。
面向平台的答案也会很棒。
问问题
2907 次
6 回答
11
一些想法
了解特定数据库引擎的详细信息，它是如何工作的
如何优化查询（提示、执行计划）
如何调整数据库（不仅是索引，还有物理存储和表示、操作系统集成）。
查询临时表之类的“技巧”来存储可以重复使用的临时结果，
如何评估非规范化对性能改进的必要性
如何使用数据库分析工具，找出瓶颈。
于 2010-09-14T18:12:28.907 回答
8
来自生产 DBA 的一些建议（我的经验是 MS SQL，但这些应该适用于其他平台）：
维护成为一个重大问题（夜间备份、DBCC、每周重新索引/优化作业等）。很容易开始超过合理的夜间或周末维护窗口。这不仅仅是一个技术问题，它也是一个业务问题（“你的意思是，从上次好的备份恢复数据库需要 4 个小时？”）
开发人员需要了解他们可能需要以不同的方式工作。“你的意思是我不能
DELETE (500m rows) FROM MassiveTable期望它起作用？
我相信我会想更多……
于 2010-09-14T18:25:37.483 回答
4
我的第一个建议是雇佣一个知道自己在做什么而不是依赖 SO 的人，否则你可能会犯一些极其昂贵的错误。我的第二个是选择合适的平台硬件和软件。细节很大程度上取决于要求。
于 2010-09-14T18:20:43.427 回答
2
Highly recommend you to read this presentation about SQL Antipatterns http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
The presentation will help (yes, it helped me a lot) find a solution to the seemingly deadlocked situation.
于 2010-09-14T18:41:26.747 回答
1
就设计和管理而言，数据库有两个方面比大小更重要。
首先是复杂性。有多少个用户表？这些表中有多少列？架构中包含数百个用户表和这些表中超过一千列的数据库非常复杂。一个有六个表的数据库并不是很复杂，即使它包含 PB 级的数据。
二是数据共享范围。如果一个数据库是为了在六个或更多应用程序之间共享数据而构建的，由不同的编程团队开发，那么您应该以与嵌入单个应用程序的数据库截然不同的方式设计和管理它。
SO 中提出的大多数数据库问题都与单个应用程序数据库有关。
除了已经提到的内容之外，还有一些需要学习的东西。
了解表分区和表分解之间的区别。有些人将表分解为具有相同列的多个表，而分区会更好地为他们服务。
了解数据的图模型和数据的关系模型之间的真正区别。有些人设计数据库时好像外键本质上与指针相同。他们最终得到的是一个系统，它可以捕捉到关系系统的所有缓慢性和图形系统的所有不可管理性。
（注意：图模型通常称为层次模型或网络模型）。
设计一个真正的关系数据库比设计一个假装是关系建模但实际上是图建模的数据库要微妙得多，也更有价值。
于 2010-09-15T12:56:00.713 回答
0
如果 RDBMS 变得非常大，尤其是在使用复杂的连接条件时，任何 RDBMS 都会遭受性能不佳的影响。数据库模式也需要设计为能够适应大量流量。大多数系统都非常擅长处理负载，但是当您有一个需要分布在多台机器上的数据库时，您也可能会遇到问题。
许多新工具正在涌现来处理数据库的可扩展性。最有前途的一种是 Memcached，它将大量数据存储在内存中，这允许更快的访问并有助于多个数据库服务器之间的同步。一些 NoSQL 解决方案，它们使用不强制模式的架构来增强传统 SQL 系统。
NoSQL 技术的一些示例是 Cassandra、CouchDB、Google BigTable、MongoDB。有些人发誓，这些系统将成为管理“即将到来的数据爆炸”的关键。
于 2010-09-14T18:18:49.463 回答