我正在建立一个数据索引，这将需要以(document, term, weight). 我将存储多达几百万个这样的行。目前我在 MySQL 中将其作为一个简单的表来执行。我将文档和术语标识符存储为字符串值，而不是其他表的外键。我正在重新编写软件并寻找更好的数据存储方式。
看看 HBase 的工作方式，这似乎非常适合模式。我可以映射document到{term => weight}.
我在单个节点上执行此操作，所以我不关心分布式节点等。我应该坚持使用 MySQL，因为它可以工作，还是尝试 HBase 是否明智？我看到 Lucene 将它用于全文索引（这类似于我正在做的事情）。我的问题实际上是单个 HBase 节点与单个 MySQL 节点相比如何？我来自 Scala，那么直接 Java API 是否比 JDBC 和 MySQL 解析等每个查询都具有优势？
我主要关心的是插入速度，因为这是以前的瓶颈。处理后，我可能最终会将数据放回 MySQL 进行实时查询，因为我需要做一些在 MySQL 中更好的计算。
我将尝试对两者进行原型设计，但我相信社区可以为我提供一些有价值的见解。
MapReduce 似乎是生成元组的好方法。如果您可以将 scala 作业放入 jar 文件中（不确定，因为我之前没有使用过 scala 并且是 jvm n00b），那么将它发送并编写一些包装器来运行它是一件简单的事情在地图上减少集群。
至于在完成后存储元组，如果您只是存储元组 ，您可能还需要考虑像mongodb这样的基于文档的数据库。
一般来说，听起来您正在对文本进行更多统计...您是否考虑过简单地使用 lucene 或 solr 来做您正在做的事情而不是自己编写？
为工作使用正确的工具。
有很多反 RDBMS 或 BASE 系统（基本可用、软状态、最终一致），而不是 ACID（原子性、一致性、隔离性、耐久性）可供选择。
我使用过传统的 RDBMS，尽管您可以存储 CLOB/BLOB，但它们没有专门为搜索这些对象而定制的内置索引。
您希望在插入文档时完成大部分工作（计算找到的每个元组的加权频率）。
您可能还想在每次搜索后对每个 (documentId,searchWord) 对的有用性进行评分。
这样，您每次都可以提供越来越好的搜索。
您还希望存储每个搜索的分数或权重以及与其他搜索相似性的加权分数。
某些搜索可能比其他搜索更常见，并且用户没有正确表达他们的搜索查询，尽管他们打算进行常见搜索。
插入文档也会导致搜索权重索引发生一些变化。
我想得越多，解决方案就越复杂。你必须先从一个好的设计开始。您的设计预期的因素越多，结果就越好。