关于选择真正快速的 DBMS 的建议

Question

我正在从事一个项目，该项目对正在传输的数据进行实时监控，并记录是否存在各种类型的错误等。CRUD 操作是实时的。我们最初计划使用 PostgreSQL，但我们面临的问题是 PostgreSQL 即使稍微调整一下也不够快，无法处理实时 CRUD 操作；MySQL和其他大人物也是如此。SQLite 的执行速度比它们快很多，但是当数据库大小达到几百 MB 时，它很快就几乎死了。另一个限制是监控是通过网络完成的。

有没有可以处理如此快速操作的数据库？还是我应该选择 NoSQL 数据库？

编辑（关于设计）：

设计尽可能地标准化。存储的数据几乎是相互独立的，因此很少有连接。另外，我说“几百 MB”只是作为参考。我们处理的实际数据库的大小为多个 GB。每秒都会插入大量数据并检索。

谈到 PostgreSQL，在我对我的数据运行的测试中，它花费的时间是 SQLite 花费的时间的 5-7 倍。

编辑（关于速度）：

我想提一个可能发生的最坏情况。

假设主应用程序正在 10 个实例（或 PC）上使用。它们都与中央 DBMS 交互并将数据插入其中。现在，每个应用程序都会有许多线程对实时传输的数据执行一些操作。该应用程序会报告流中是否存在错误数据。而且由于数据是在数据包级别进行分析的，因此一秒钟内可能会发生大量错误。根据一些非常基本的计算，最坏的情况可能需要每个实例每秒约 3k 行的插入速率，每行有大约 8-10 个相关列。我在我的机器（4GB 内存，QuadCore）上测试了这样的测试，SQLite 能够在大约 1 秒内通过网络完成这个测试。我稍微调整了 PostgreSQL，它在大约 5 秒内完成了同样的工作（我承认我没有对其进行很多优化，因为我不是 DBMS 领域的专家）。但瓶颈随着 SQLite 中数据库大小的增长而出现；插入看起来几乎没问题，但读取需要很多时间。我自己用 3gb 的 DB 大小对其进行了测试。

我们主要关心的是插入，在最坏的情况下，每个应用实例大约有 3k 次插入，平均每个实例大约有 500-1k 次插入。

Answer 1

如果您不能扩展主要的 RDBMS，那么您的数据库设计（包括索引、查询等）或硬件是错误的。平台的选择几乎无关紧要。

就是这么简单。特别是当您提到“几百兆字节”时，这意味着低容量（我的意思是每秒写入几十次）