我将拥有一个包含 uuid、年龄、性别、家庭收入和 12 个这样的字段的用户表数据库。其中大约有 40 - 5000 万。我需要根据年龄范围、收入范围等进行查询，并获取 uuid 的列表。如果连接，每行应该是大约 400 个字符。将 400 字节乘以 50Mil 得到大约 17 - 18 GB 约。它会增长，但速度很慢。
这将是保存这些数据并执行快速查询的最佳数据库系统。蒙戈还是 MySQL？另外，最好保留哪种硬件。
另外，有人可以根据经验告诉 mySQL 或 Mongo 的查询时间吗？我需要在此基础上设计整个系统的一些其他组件的架构。
我不会说 40-50 百万条记录或 17-18GB 将被视为“大”。任何关系数据库都应该足够了。
任何现代服务器都足够了。Windows、Linux - 选择您最了解的那个。我想说64位是必需的。添加足够的 RAM，您就可以将整个内容保存在内存中。
没有人能告诉您查询时间，因为它取决于太多因素：硬件、模式、索引等。最好的办法是自己计时并查看。
我认为您最大的问题将是按范围查询。这听起来不太像事务数据库，而更像是数据挖掘仓库。也许具有时间、位置、收入等维度的星型模式更适合您尝试做的事情。
没有理由将所有这些信息存储在一个表中，尤其是具有那么多行的表。对于这么大的项目，我强烈建议学习关系数据库的工作原理以及索引的工作原理。您将要实现的方式在您投入的任何数据库或硬件上都会很慢。如果您将其设计为关系数据库，使用几个单独的表来存储内容并使用外键访问其他表，那么您将大大提高性能。
这很干，但必不可少。你真的应该试着去很好地理解它。
此外，您应该阅读有关索引的内容。每个数据库的功能都略有不同，因此您如何实现它取决于您选择的数据库。
我的意思是你会大大提高你的表现。我已经看到并重新设计了耗时 15-20 分钟的糟糕查询，通过关系数据库设计、索引和优化查询设计对它们进行了优化，并将它们减少到毫秒。