MySQL和NoSQL：帮助我选择正确的

Question

MySQL和NoSQL：帮助我选择正确的有一个很大的数据库，1，000，000，000行，称为线程(这些线程实际上存在，我不会仅仅因为我喜欢它就让事情变得更困难)。线程中只有几个东西，以加快速度：(int id、String散列、int应答计数、int dateline(时间戳)、int forumid、String title)查询：select * from thread where forumid = 100 and replycount > 1 order by dateline desc limit 10000, 100因为有1G的记录，这是一个很慢的查询。所以我想，让我们把这1G的记录分成几张表格，就像我拥有的一样多的论坛(类别)！差不多完美了。有很多表，我的搜索记录较少，而且速度更快。查询现在变成：select * from thread_{forum_id} where replycount > 1 order by dateline desc limit 10000, 100这真的更快，99%的论坛(类别)，因为其中大多数只有少数几个主题(100k-100万)。然而，由于有一些记录大约有1000万条，所以有些查询仍然要慢下来(0.1/2秒)，对于我的应用程序来说太慢了！我已经在用索引了！).我不知道如何使用MySQL来改进它。有办法吗？对于这个项目，我将使用10台服务器(12 GB内存，4x7200 rpm硬盘上的软件RAID 10，四核)这样做的目的是简单地将数据库拆分到服务器之间，但是由于上面解释的问题，这个问题仍然是不应该存在的。如果我在这10台服务器上安装了Cassandra(假设我找到了使其正常工作的时间)，那么是否应该提高性能呢？我该怎么办？在多台机器上继续使用带有分布式数据库的MySQL，还是构建Cassandra集群？我被要求发布什么是索引，如下所示：mysql> show index in thread;PRIMARY id forumid dateline replycount选择“解释”：mysql> explain SELECT * FROM thread WHERE forumid = 655 AND visible = 1 AND open <> 10 ORDER BY dateline ASC LIMIT 268000, 250;+----+-------------+--------+------+---------------+---------+---------+-------------+--------+-----------------------------+| id | select_type | table  | type | possible_keys | key     | key_len | ref         | rows   | Extra                       |+----+-------------+--------+------+---------------+---------+---------+-------------+--------+-----------------------------+|  1 | SIMPLE      | thread | ref  | forumid       | forumid | 4       | const,const | 221575 | Using where; Using filesort | +----+-------------+--------+------+---------------+---------+---------+-------------+--------+-----------------------------+

Answer 1

有一部分问题与NoSQL或MySQL选项有关。事实上，这是隐藏在这里的一件基本事情。SQL语言对人来说很容易写，对计算机来说也很难读。在大容量数据库中，我建议避免SQL后端，因为这需要额外的步骤命令解析。我已经做了大量的基准测试，在某些情况下，SQL解析器是最慢的。你对此无能为力。好的，您可以使用预解析语句并访问它们。

顺便说一句，它并不广为人知，但MySQL是从NoSQL数据库中发展出来的。MySQLDavid和Monty的作者工作的公司是数据仓库公司，他们常常不得不为不寻常的任务编写自定义解决方案。这导致了大量用于手工编写数据库函数的自制C库，而Oracle和其他库的性能很差。SQL于1996年被添加到这个有近20年历史的动物园中，以求取乐。你知道之后发生了什么。

实际上，使用MySQL可以避免SQL开销。但通常情况下，SQL解析不是最慢的部分，而是很好的了解。要测试解析器开销，只需为“SELECT 1”进行基准测试；)。