我有一个 300GB 的文件，我需要一些如下所示的行。从下面显示的行中，我只需要以 . 开头的行>miR。

我已经编写了一个 Perl 程序，它实际上打印了我想要的输出，但是当我将相同的代码应用于高达 300 GB 数据的更大文件（如下所示的类似行）时，如何进行呢？是否有任何替代方法可以在此代码中实现，因为如果代码运行，它就会被杀死。

.

我们有一个看起来像这样的 MySQL 表（删除了无关紧要的列）：

表中有大约 900M 行，其中一个 account_id 占这些行的 65% 以上。我被要求为 created_ts 和 issue_ts 编写跨日期范围的查询，这些查询依赖于 account_id，它似乎对自动增量键具有 1:1 的功能依赖性。

一个典型的查询如下所示：

查询的解释显示：

问题是查询花费的时间太长并且最终被杀死。我已经让它运行了几次，它导致数据库主机停机，因为操作系统（Linux）用完了交换空间。

我反复研究过这个问题，并试图将查询分解为不相关的子查询、强制索引、使用显式 SELECT 子句并限制日期范围的窗口，但结果是一样的：性能差（太慢）并且对宿主过于繁重（总是死亡）。

我的问题是：

1. 是否可以制定查询以将数据分割成日期范围并在实时调用中可接受地执行？( < 1s)

2. 为了获得我被要求获得的性能，我是否缺少或可能有帮助的优化？

欢迎任何其他建议、提示或想法。

谢谢

我想知道如何在 Hadoop/HDFS/Hbase 中对数据进行版本控制。它应该是您模型的一部分，因为很可能会发生变化（长时间收集大数据）。

HDFS（基于文件的后端）的主要示例。

样本日志文件.log：

我现在想知道在哪里添加版本信息。我看到了两种选择：

文件格式内的版本

日志文件.log：

文件名中的版本

*日志文件_V1.log*

*日志文件_V2.log*

第二个选项（文件名中的版本）对我来说感觉更干净并且适合 HDFS（我可以简单地使用 *_v2* 作为排除旧版本样式文件的模式）。另一方面，我需要运行 2 个不同的作业，因为我无法在一个作业中分析版本片段。

HBase 怎么样，我猜在 HBase 中版本肯定会在另一个表列中结束（HDFS 是实现细节并用作 HBase 的后端）？

用于后端 Hadoop/HDFS/HBase 的版本控制数据的任何其他替代方法？

谢谢！

编辑：我的问题与如何处理版本信息本身有关，而不是时间戳。

LevelDB 是来自 Google 的一个非常有趣的 C++ 数据存储。我正在 Java 世界中寻找类似的东西（坦率地说，这样我可以更好地理解代码，更容易在 Windows 上运行，等等）。

我了解 Hbase 和 Cassandra 也包含相同的基本技术：用于文件存储的 sstable、用于内存存储的 memtable（在排序和写入磁盘之前）、某种压缩、定期压缩等。

是否有任何努力从更大的项目中提取这项技术？我自己已经开始查看代码库（主要是 Cassandra），但这些显然不是微不足道的项目。哪个项目有更多的模块化代码？

期待大家的指点！

通过在 hive 中使用 ORDER BY，它只使用单个 reducer。所以 ORDER BY 是低效的。是否有可用于 ORDER BY 的替代解决方案。

问候， 拉托

我的背景是生物信息学，尤其是下一代测序，但问题是通用的；所以我将以一个日志文件为例。

该文件非常大（千兆字节大，已压缩，因此无法放入内存），但易于解析（每一行都是一个条目），因此我们可以轻松编写如下内容：

现在，我想从日志文件中计算出很多统计数据。编写单独的函数是最简单的，例如：

所有这些都是形式foldl' k z . map f。

问题是，如果我尝试以最自然的方式使用它们，比如

这将在内存中分配整个列表，这不是我想要的。我希望折叠同步完成，以便可以对 cons 单元进行垃圾收集。如果我只计算一个统计数据，就会发生这种情况。

我可以编写一个大函数来执行此操作，但它是不可组合的代码。

或者，这就是我一直在做的，我分别运行每个通道，但这每次都会重新加载和解压缩文件。

我将拥有一个包含 uuid、年龄、性别、家庭收入和 12 个这样的字段的用户表数据库。其中大约有 40 - 5000 万。我需要根据年龄范围、收入范围等进行查询，并获取 uuid 的列表。如果连接，每行应该是大约 400 个字符。将 400 字节乘以 50Mil 得到大约 17 - 18 GB 约。它会增长，但速度很慢。

这将是保存这些数据并执行快速查询的最佳数据库系统。蒙戈还是 MySQL？另外，最好保留哪种硬件。

另外，有人可以根据经验告诉 mySQL 或 Mongo 的查询时间吗？我需要在此基础上设计整个系统的一些其他组件的架构。

Orient 版本：官方分发 OrientDB Graph Edition 1.0.1

我正在尝试使用 OrientDB SQL 插入构建蓝图兼容图（比 g.addVertex 快并且没有 OutOfMemory 错误）。

创建 150 万条记录时，通过控制台（批处理）插入的时间比预期的要长（四核 i7 上为 13 分钟），并且通过“名称”字段搜索非常慢（2 分钟）。

出于测试目的，我们有一个非常简单的导入 sql 文件，它尝试创建与两个设置参数 name:account_id 和 type:account_type 以及空输入/输出数组兼容的蓝图顶点。

进口.ornt：

注意：最好能够将记录标识符设置为我们预先存在的 account_id。但我不确定如何尝试这个。

上面的 sql 最终约为 100MB，我通过控制台运行它（console.sh 包括优化-Dmvrbtree.optimizeThreshold=-1）：

在这一点上，我们有了基本的 OrientDB 图形，其中 OGraphVertex 类大约有 150 万个顶点。

使用控制台，通过 Orient SQL 或 Gremlin/Pipes 进行选择需要很长时间：

使用 OrientDB SQL 或 Gremlin 大约需要 2 分钟！

作为一种潜在的解决方法，最好将记录标识符设置为来自 MySQL 数据库源的原始帐户 ID。是否可以有自定义记录 ID？

例如，由于我们会在开始遍历时知道 account_id（例如 1149400），所以理想的情况是：

0.054000 比 112.531 快很多！！

给定带有索引“名称”（唯一或非唯一）的基本蓝图兼容 OrientGraph，如果需要，有什么建议可以改进以下内容？

注意：我找不到使用索引加载 [blueprints] 顶点的权威指南。我有一个大图，使用 has('name','bob') （在控制台中）需要 2 分钟！另一方面，基于索引的搜索以毫秒为单位返回。

到目前为止我想出的最好的：

目前我有一个应用程序，用户可以在其中上传文档（pdfs/excel/word，少量图片）。在哪里可以寻找大数据（Hadoop-MangoDB）解决方案

1. 存储数千个 pdf、word、excel 文件（因为我们的大小也在增长）

2. 搜索图像元信息

3. 全文搜索（大部分是实时的）

4. 更快的检索

请指教