如何有效地处理数十亿条记录？

Question

我有一个性能问题，在使用select查询处理十亿条记录时，我有一个表

CREATE TABLE `temp_content_closure2` (
  `parent_label` varchar(2000) DEFAULT NULL,
  `parent_code_id` bigint(20) NOT NULL,
  `parent_depth` bigint(20) NOT NULL DEFAULT '0',
  `content_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  KEY `code_content` (`parent_code_id`,`content_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY KEY (parent_depth)
PARTITIONS 20 */ |

我使用了partition，它可以通过对表进行细分来提高性能，但在我的例子中没有用，我的示例select在这个表中

+----------------+----------------+--------------+------------+
| parent_label   | parent_code_id | parent_depth | content_id |
+----------------+----------------+--------------+------------+
|  Taxonomy |          20000 |            0 |        447 |
| Taxonomy |          20000 |            0 |       2286 |
|  Taxonomy |          20000 |            0 |       3422 |
| Taxonomy |          20000 |            0 |       5916 |
+----------------+----------------+--------------+------------+

这里的content_id对于parent_dept来说将是唯一的，所以我使用parent_depth作为partitioning.In的关键字，每个深度我有2577833行要处理，所以在这里分区是没有用的，我从网站上得到了一个使用归档存储引擎的想法，但它将使用全表扫描，而不是在select中使用索引，基本上99%我在这个表中使用select查询，这个表将增加它的计数，我在mysql数据库中有一个5.0.1版本的day.currently。如果您建议使用nosql，那么我可以使用cassandra还是accumulo？

Answer 1

添加如下索引：

ALTER TABLE table ADD INDEX content_id ('content_id')

如果您有更具体的选择条件，还可以添加多个索引，这也会加快速度。

Multiple and single indexes

总体而言，如果您有一个像这样一个增长如此之快的表，那么您可能应该考虑重构您的sql设计。

也可以查看“大数据”解决方案。

Answer 2

有了这样的数据量和大小，你需要在一个机器集群中设置一个分片的MySQL设置(Facebook和Twitter在一个分片的MySQL设置上存储了大量的数据，所以这是可能的)，或者使用一个基于大表的解决方案，在不同集群的节点之间本地分布数据- Cassandra和HBase是这里最受欢迎的选择。您必须意识到，单台计算机上的10亿条记录几乎会达到系统的所有限制-首先是IO，然后是内存，然后是CPU。这根本是不可行的。

如果你使用Big Table的方式，Cassandra将是最快的设置和测试。但是，如果您预计会有map-reduce类型的分析需求，那么HBase与Hadoop生态系统的集成会更紧密，应该会运行得很好。在性能方面，它们都是并驾齐驱的，所以请随意选择。