c# - 需要数据库建议->柱状，嵌入式(如果可能)

Question

编辑:作为到目前为止的答案的结果，我想将更多的注意力集中在我想归零的内容上:一个数据库，该数据库允许在内存中写入内存(可以是简单的C#代码)，并具有对存储选项的持久性以便访问数据到目前为止，从R. Redis内部看来，这是最有前途的。我还考虑实际使用类似于Lockfree++或ZeroMQ的方法，以避免同时将数据写入数据库，而是通过消息总线/其他实现发送所有要保留的数据，并让一个“角色”处理所有写入操作到内存数据库或其他解决方案。除了Redis(还有一些提到的SQLite，我将仍然需要测试其性能)之外，还有其他想法。还有其他建议吗？

我正在寻找理想的数据库结构/解决方案，该结构/解决方案满足我的以下大多数要求，但到目前为止我还是完全失败了。你能帮忙吗？

我的任务:我在.Net 4.5(C#)中运行一个进程，并生成(通常)要在其他应用程序中用于进一步分析的值类型，因此希望保留在内存中或保留在磁盘上。下面更多。数据是在不同的任务/线程中生成的，因此基于行的数据格式不能很好地适应这种情况(因为在不同的线程中生成的数据是在不同的时间生成的，因此未对齐)。因此，我认为列式数据结构可能合适，但是如果我错了，请纠正我。

例子:

任务/线程1在给定的时间戳记下生成以下数据

datetime.ticks/输出数据值

1000000001 233.23

1000000002 233.34

1000000006 234.23
...

Taks/Thread＃2在给定的时间戳记下生成以下数据

datetime.ticks/输出数据值

1000000002 33.32

1000000005 34.34

1000000015 54.32
...

我不需要在.Net运行时对齐时间戳，在保存数据并稍后再在R或Python中处理数据之后，我首先要做的是。

我的要求:

快速写入，快速写入，快速写入:可能发生的情况是，我每秒生成100,000-1,000,000个数据点，并且需要保留(最坏的情况)或将数据保留在内存中。可以在自己的线程上运行写操作，这样该过程可以滞后于数据生成过程，但限制为16gb RAM(64位代码)，更多内容如下。

首选项适用于列式db格式，因为它很适合以后我要查询数据的方式，但是如果对上述示例有意义，我可以采用任何其他结构(如果其他所有参数，文档/键值也可以)满足要求，特别是在写入速度方面)。

可以从.Net内部引用的

API。例子:HDF5可能被某些人认为是有能力的，但是我发现他们的.Net端口太可怕了。如果能更好地支持.Net的东西会是一个加号，但是如果满足所有其他要求，那么我可以处理类似于HDF5 .Net端口的东西。

如果可能的话，并发写入:如前所述，我喜欢同时从不同的任务/线程中写入数据。

我受到16gb内存(以64位运行.Net进程)的约束，因此我可能会寻找一些不完全是内存中的内容，因为有时我可能会生成更多的数据。有时会持久存在的内存中的某种事物或纯粹的持久性模型可能是更可取的。

嵌入式的首选项，但是如果客户端/服务器解决方案中的服务器可以作为Windows服务运行，则没有问题。

在数据访问方面，我非常喜欢db解决方案，因为该解决方案已经存在R和Python的接口(interface)，因为我喜欢在Python中使用Panda库进行时间序列比对和其他分析，并在R中运行分析。

如果API/库还支持类似SQL/SQL/Linq/这样的查询，那将是非常棒的，但是通常我只需要绝对裸露的骨骼，例如在开始和结束日期之间加载列数据(给定“键”/索引采用这种格式)，因为我在R/Python中分析并运行查询。

如果附带管理控制台或数据可视化工具，那么这是一个加号，但不是必须的。

应该是开源的，或者在“范围”之内定价(不，KDB在这方面没有资格；-)

好的，这是我到目前为止所拥有的，再说一次，我得到的一切，因为大多数数据库解决方案仅在写入性能要求上就已经失败了:

Infobright和Db4o。我喜欢到目前为止所读的内容，但我承认我没有检查任何性能统计信息

我自己做了些事情。我可以轻松地以二进制格式存储值类型并通过datetime.ticks索引数据，我只需要以某种方式编写脚本以在Python/R中加载/反序列化数据即可。但是，如果我想添加并发，查询引擎和其他功能，那将是一项艰巨的任务。因此，我正在寻找已经存在的东西。

Answer 1

我无法发表评论-低代表(我是新来的人)-因此您得到的是完整答案...

首先，您确定完全需要一个数据库吗？如果您最关心的是快速写入速度和对R的可移植性，那么您是否刚刚考虑过使用平面文件机制？根据您的评论，您愿意批量写出，但是您需要持久性；如果这些是我的要求，那么我会编写一个快速的磁盘直接缓存系统，然后构建一个单独的任务，该任务定期获取磁盘文件并将它们移至R的数据存储中，并且仅当R读取Flat首先，文件还不够。

如果您可以事后进行对齐，则可以在主并行循环中编写线程以分离文件，每隔一段时间就切掉每个文件，并将对齐和数据库加载留给子进程。

因此，(用cr脚的pseudo_code)，构建一个将由backgroundworker或类似对象调用的线程进程，并包括一个唯一标识每个工作线程以及每个文件流(任务/线程)的线程名字符串:

file_name = threadname + '0001.csv' // or something
open(file_name for writing)
while(generating_data) {
    generate_data()
    while (buffer_not_full and very_busy) {
        write_data_to_buffer
        generate_data()
    }
    flush_buffer_to_disk(file_name)
    if(file is big enough or enough time has passed or we're not too busy) {
        close(file_name)
        move(file_name to bob's folder)
        increment file_name
        open(file_name for writing)
    }
)

高效，快速的文件I/O和缓冲是 a straightforward and common problem。没有比这更快的了。然后，您可以编写另一个进程来完成数据库的加载，而不会消耗那里的性能:

while(file_name in list of files in bob's folder sorted by date for good measure)
{
    read bob's file
    load bob's file to database
    align dates, make pretty
}

而且我不会用C#编写该部分，而是对其进行批处理脚本并使用数据库的 native 加载器，该加载器的速度将与您从头开始构建的任何东西一样快。

如果您在同一硬件上运行，则必须确保两个循环不会造成太大干扰。也就是说，以更高的优先级运行任务线程，或内置一些互斥锁或性能限制器，以便在线程运行时数据库负载不会占用资源。我一定会隔离数据库服务器和硬件，以便不损害平面文件的文件I/O。

如果您在Unix上，则FIFO队列可以工作，但实际上并非如此。 :-)

而且，我想，与数据库引擎相比，硬件对您的性能影响更大。如果您的预算有限，那么我猜您正在使用COTS硬件，因此，升级固态硬盘的价格可能会相当便宜。正如我所说，将数据库存储与平面文件存储分开会有所帮助，并且R，数据库和线程的CPU/RAM都应该理想地分开。

我的意思是，除非您有很多钱可以花，否则选择数据库供应商可能不是您最大的问题。否则，大多数时候您将受到硬件的束缚。数据库调优是一门艺术，虽然您可以在高端获得些微的性能提升，但是拥有一名优秀的数据库管理员将使大多数数据库保持相同的性能。我会看一下R和Python的良好支持，而您对此感到满意。如果您以柱状方式考虑，那么请看一下R和C#对Cassandra，Hana，Lucid，HBase，Infobright，Vertica等的支持(我的投票)，然后根据价格和支持选择一个。对于在一台商用机器上的传统数据库，我还没有看到MySQL无法处理的任何事情。