你有没有使用NoSQL数据存储库遇到了哪些可伸缩性问题？ [关闭]

问题描述 投票：189回答：15

NoSQL的是指用关系数据库和ACID担保的历史突破非关系型数据存储。流行的开源NoSQL数据存储包括：

  • Cassandra（表格，用Java编写的，由思科，WebEx的，Digg的脸谱，IBM，马洛，Rackspace公司，Reddit和Twitter的使用）
  • CouchDB（文件，Erlang编写，由BBC和Engine Yard的使用）
  • Dynomite（键值，Erlang编写，由Powerset的使用）
  • HBase（键值，用Java编写的，由兵使用）
  • Hypertable（片状，用C ++编写，由百度使用）
  • Kai（键值，Erlang编写）
  • MemcacheDB（键值，用C，由书签交易使用）
  • MongoDB（文件，用C ++编写，由美国艺电，Github上，纽约时报和Sourceforge上使用）
  • Neo4j（图中，用Java编写的，通过一些瑞典大学使用）
  • Project Voldemort（键值，用Java编写的，通过LinkedIn使用）
  • Redis（键值，用C，通过Craigslist的，发动机堆场和Github上使用）
  • Riak（键值，Erlang编写，由Comcast和年糕媒体使用）
  • Ringo（键值，Erlang编写，由诺基亚使用）
  • Scalaris（键值，Erlang编写，由OnScale使用）
  • Terrastore（文件，用Java编写的）
  • ThruDB（文件，用C ++编写，由JunkDepot.com使用）
  • Tokyo Cabinet/Tokyo Tyrant（键值，用C语言编写，通过Mixi.jp使用（日本社交网站））

我想知道具体的问题你 - SO阅读器 - 使用数据存储和你使用什么NoSQL数据存储库已经解决了。

问题：

  • 有什么可扩展性问题有您使用NoSQL数据存储解决？
  • 你用什么NoSQL数据存储库？
  • 什么数据库你在切换到NoSQL数据存储库使用？

我在寻找第一手的经验，所以请不要回答，除非你有。

database nosql key-value-store graph-databases distributed-database
15个回答
49
投票

我已经关掉一个小的子项目从MySQL到CouchDB的，要能够处理负载。其结果是惊人的。

大约2年前，我们已经发布了http://www.ubuntuusers.de/自行编写的软件（这可能是德国最大的Linux社区网站）。该网站是用Python编写的，我们已经增加了一个WSGI中间件这是能够捕获所有异常，并将它们发送到另一个小MySQL支持的网站。这个小网站使用散列值来确定不同的错误，并存储出现的次数和最后一次出现为好。

不幸的是，在发布后不久，回溯记录器的网站没有回应了。我们有与被抛出异常几乎每一个请求，我们的主网站，以及其他几个错误，这是我们没有在测试阶段探索的生产分贝一些锁定问题。我们的主网站的服务器集群，称为回溯记录器每秒提交页面数k次。这是一种方式太多主办了追踪记录器（它已经是一个旧的服务器，这是仅用于开发目的）的小型服务器。

这时的CouchDB是相当受欢迎，所以我决定尝试一下，写一个小回溯记录器与它。新的记录仅由单个Python文件，这与分类和过滤选项和一个提交页面提供一个错误列表。并在后台我已经开始了一个CouchDB的过程。新的软件非常迅速做出反应的所有要求，我们能够看到的自动错误报告的巨量。

有趣的是，该解决方案之前，是一个古老的专用服务器，而另一方面新的基于CouchDB的网站只在一个共享的Xen实例资源非常有限运行上运行。而且我还没有使用的键值存储的实力水平扩展。 CouchDB的/二郎OTP来处理并发请求没有锁定任何东西的能力已经足以满足需求。

现在，赶紧写的CouchDB，回溯记录器仍在运行，是探索主要网站上的bug一个有用的方法。无论如何，约每月一次的数据库变得太大，CouchDB的进程就会被杀死。但随后，CouchDB的紧凑-DB命令再次减少了从几个GB一些KB的大小和数据库再次启动并运行（也许我应该考虑增加一个cronjob有... 0°）。

在总结，CouchDB的肯定是这个子项目的最佳选择（或者至少比MySQL更好的选择）和它的工作好。

2
投票

我不。我想用一个简单且免费的key-value存储，我可以打电话的过程，但这样的事情不会在Windows平台上AFAIK存在。现在，我使用SQLite，但我想使用像东京柜。 BerkeleyDB的有牌照“问题”。

但是，如果你想使用Windows操作系统的NoSQL数据库的选择是有限的。并没有总是一个C＃提供商

我曾尝试MongoDB的，这是比SQLite的快40倍，所以也许我应该使用它。但我还是希望在过程中解决的简单。

2
投票

我使用Redis的存储跨机器的日志信息。这是很容易实现，而且非常有用的。 Redis的真岩

2
投票

我们更换了Postgres数据库与CouchDB文档数据库，因为没有一个固定的模式是一个强大的优势给我们。每个文档具有可变数量的用于访问文件的索引。

1
投票

我已经在过去使用Couchbase，我们遇到的再平衡问题和其他问题的主机。目前我在几个生产项目中使用Redis的。我使用redislabs.com这是一个Redis的托管服务，它扩展您的Redis的集群服务。我已经发表了关于对象持久化的视频在我的博客http://thomasjaeger.wordpress.com显示如何在提供者模型使用Redis的，以及如何在C＃的对象存储到Redis的。看一看。

1
投票

我会鼓励任何人阅读此尝试Couchbase一次，现在3.0是出了门。有对于初学者超过200项新功能。 Couchbase Server的性能，可用性，可扩展性和易于管理的功能，使一个非常灵活，高可用数据库。管理UI是内置的，因此没有必要从应用程序到数据库的负载平衡器的API自动发现群集节点。虽然我们不会在这个时候有一个托管服务，您可以对之类的东西AWS，RedHat的齿轮，Cloudera的，Rackspace公司，Docker容器一样的Cloudsoft，以及更多couchbase运行。关于重新平衡它取决于你指什么专门但Couchbase不会自动节点故障后重新平衡，如设计，但管理员可以设置自动故障转移的第一个节点失效，并使用我们的API，您还可以访问到副本vbuckets对于之前使他们主动或使用RESTAPI可以强制通过一个监测工具故障切换阅读。这是一个特殊的情况，但可以做。

我们往往不会重新平衡几乎任何模式，除非节点是完全脱机，从不回来还是一个新的节点准备好自动平衡英寸这里有几个导游，以帮助有兴趣的人看到的最高效能的NoSQL数据库的一个是怎么一回事。

  1. Couchbase Server 3.0
  2. Administration Guide
  3. REST API
  4. Developer Guides

最后，我还要鼓励你检查出N1QL分布式查询：

  1. N1QL Tutorial
  2. N1QL Guide

感谢您的阅读，让我或其他人知道，如果你需要更多的帮助！

奥斯汀

0
投票

我已经使用Vertica的在past.It依赖于列式压缩和加速磁盘读取和降低存储需求，以充分利用您的硬件。更快的数据负载和更高的并发性，您可以将分析数据，以更多的用户以最小的延迟。

此前，我们查询其数十亿条记录和性能Oracle数据库是非常次优的。在查询了8至12秒来运行，即使SSD优化后。因此，我们觉得有必要使用更快的读取优化，分析面向数据库。随着精益服务层后面Vertica的集群，我们可以运行在一秒性能的API。

在优化查询执行的格式突起Vertica的存储数据。类似物化视图，突出店面的结果集在磁盘或SSD，而他们是在query.Projections每次使用时比计算它们具有以下优点：

  1. 压缩和编码数据以减少存储空间。
  2. 简化跨数据库集群分布。
  3. 提供高可用性和恢复。

Vertica的优化通过使用分割跨集群分布数据的数据库。

  1. 分割放置数据的一部分的节点上。
  2. 它均匀地在所有节点上分布数据。因此，每个节点执行一块查询过程的。
  3. 查询集群上运行，并且每个节点接收查询计划。
  4. 查询的结果汇总并用于创建输出。

有关详细信息，请参阅Vertica的文档@ https://www.vertica.com/knowledgebase/

50
投票

我现在的项目实际上。

存储在归一化的结构18000点的对象：在8个不同的表90000点的行。耗时1分检索，并将它们映射到我们的Java对象模型，这是一切正确索引等。

将它们存储作为使用轻量级文本表示的键/值对：1个表，18000行，3秒后对它们进行检索所有与重建的Java对象。

在业务方面：第一个方案是不可行的。第二个选项意味着我们的应用程序的作品。

技术细节：在MySQL上运行SQL和NoSQL的！与MySQL坚持良好的事务支持，性能和不破坏数据的良好记录，比例还算不错，支持集群等。

我们在MySQL数据模型现在只是重点领域（整数）和大“值”字段：只是一个大的文本字段基本。

我们没有与任何新球员（CouchDB的，卡桑德拉，MongoDB的，等等）去，因为尽管他们各自在自己的权利提供了极大的功能/性能，总有弊端我们的情况下（例如缺少/不成熟的Java支持）。

使用MySQL（AB）的额外的好处 - 那些以关系工作我们的模型中的位可以很容易地联系到我们的键/值存储数据。

更新：这里有我们如何表示的文本内容，而不是我们的实际业务领域的例子作为我boss'd拍我（我们不以“产品”工作），但传达的理念，包括递归方面（一个实体，在这里一种产品，“含有”等）。希望这清楚如何在标准化的结构，这可能是相当多的表，例如加入一个产品到其范围的风味，这是其他产品包含等

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
22
投票

托德·霍夫的highscalability.com有很多的NoSQL的覆盖面很大，包括一些案例研究。

商业Vertica柱状DBMS可能适合您的需要（即使它支持SQL）：它的速度非常快与分析查询传统的关系型DBMS比较。见斯通布雷克等人的recent CACM paper对比Vertica的地图 - 减少。

更新：而且Twitter's selected Cassandra了几个人，包括HBase的，伏地魔，MongoDB的，MemcacheDB，Redis的，和Hypertable的。

更新2：里克·卡特尔刚刚出版了几NoSQL系统的High Performance Data Stores比较。而highscalability.com对里克的纸的看法是here。

8
投票

我们感动我们的数据的一部分，从MySQL到MongoDB的，没有那么多可扩展性，但更多的是因为它是一个更适合文件和非表格数据。

在生产中，我们目前存储：

  • 25000页的文件（60GB）
  • 1.3亿其他“文件”（350GB）

周围10GB的每日成交额。

该数据库部署在两个节点（6x450GB SAS RAID10）使用所述mongodb的蟒API（pymongo）阿帕奇/ WSGI /蟒客户端“配对”的配置。磁盘设置可能是矫枉过正，但是这就是我们所使用的MySQL。

除了一些问题pymongo线程池和MongoDB服务器的阻塞性质，它一直是一个很好的经验。

5
投票

我换去对你的大胆的文字，因为我没有任何的第一手经验道歉，但是这组博客文章是解决使用CouchDB问题的一个很好的例子。

CouchDB: A Case Study

从本质上讲，textme应用程序中使用CouchDB的处理他们的数据爆炸问题。他们发现，SQL是处理大量归档数据的速度太慢，并且移动它交给CouchDB的。这是一个很好的阅读，他讨论搞清楚什么问题的CouchDB可以解决的全过程，以及它们如何最终解决这些问题。

5
投票

我们已将我们的一些数据，我们使用PostgreSQL中存储和Memcached的成Redis。关键值存储是存储分层对象数据更适合。您可以更快，用少得多的开发时间和精力比使用ORM映射你的BLOB的RDBMS存储BLOB数据。

我有一个open source c# redis client，让您存储和检索与1号线的任何POCO对象：

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Key值店也为“向外扩展”容易得多，你可以添加新的服务器，然后均匀地划分您的负载，包括新的服务器。重要的是，没有中央服务器，它会限制你的可扩展性。 （虽然你仍然需要一致性哈希的策略来分发您的要求）。

我认为Redis的是对类固醇“管理文本文件”，它提供了多个客户端快速，并行和原子访问，所以任何我曾经使用文本文件或嵌入式数据库我现在使用Redis的。例如为了得到一个实时结合我们的所有服务滚动错误日志（已出了名的是一个艰难的任务，对于我们），现在也已实现，只有通过公正的错误预挂起到Redis的服务器端列表，然后几行修剪列表，以便只有最后1000保持在例如：

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);
4
投票

我没有第一手的经验，但我发现this博客文章挺有意思的。

3
投票

我觉得努力软件领域对象（例如aSalesOrder，aCustomer ...）映射到二维关系型数据库（行和列）需要大量的代码来保存/更新，然后再以实例从多个表的域对象实例。更何况有所有这些性能命中连接，所有的磁盘读取...只是查看/操纵域对象，如销售订单或客户记录。

我们已经切换到对象数据库管理系统（ODBMS）。他们是超越列出的NoSQL系统的能力。 （对于Smalltalk的）宝石/ S是这样的例子。有迹象表明，有许多语言驱动程序的其它ODBMS解决方案。主要开发者的利益，你的类层次结构将自动为您的数据库架构，子类和所有。只需使用你的面向对象的语言，使对象持久化到数据库中。 ODBMS系统提供的酸水平诚信交易，所以它也将在金融系统工作。

3
投票

我从MySQL（InnoDB的）切换到卡桑德拉对于M2M系统，它基本上存储的时间序列对于每一个设备的传感器。各数据由（DEVICE_ID，日期）和（DEVICE_ID，type_of_sensor，日期）索引。 MySQL的版本包含20个百万行。

MySQL的：

  • 设置在主 - 主同步。很少有问题出现各地同步的损失。这是紧张，尤其是在开始可能需要数小时来解决。
  • 插入时间是不成问题的，但查询需要越来越多的内存作为数据增长。问题是索引作为一个整体考虑。就我而言，我只是使用了必要的内存加载索引（该设备只有少数％的人经常监测，它是在最近的数据）的非常薄的部分。
  • 这是很难备份。 Rsync是无法做到的大InnoDB表文件的快速备份。
  • 它很快变得清晰，这是不可能的更新重表的模式，因为它花了太多的时间（小时）。
  • 导入数据需要数个小时（甚至当索引在年底完成）。最好的救援计划是要始终保持对数据库（数据文件+日志）的几个拷贝。
  • 从一个托管公司移动到另一个是真正的大问题。复制必须非常小心处理。

卡桑德拉：

  • 更容易安装比MySQL。
  • 需要大量的RAM。 2GB的实例无法使其在第一版本中运行，现在它可以在1GB的情况下工作，但它不是想法（太多的数据刷新）。给它8GB足以在我们的案例。
  • 一旦你了解你如何组织你的数据，存储方便。请求是有点复杂。但是，一旦你得到它周围，它是非常快（你不能真的错，除非你真的想）。
  • 如果前面的步骤做的权利，它是并保持超高速。
  • 它似乎像数据组织待备份。每一个新的数据被添加为新文件。我个人，但是，每天晚上刷新数据这不是一个好东西，每次关机（通常为升级），以便恢复花费较少的时间，因为我们少日志读取之前。它不会创造太多的文件是它们被压缩。
  • 导入数据是快得要命。而更多的主机，你有更快。导出和导入千兆字节的数据是不是一个问题了。
  • 没有一个模式是一个非常有趣的事情，因为你可以让你的数据演变遵循您的需求。这可能意味着在同一时间在同一列族有不同版本的数据。
  • 添加主机很容易（虽然不是快），但我还没有做到在一个多数据中心安装。

注：我也用elasticsearch（基于Lucene面向文档的），我认为它应该被视为一个的NoSQL数据库。它是分布式的，可靠的和经常快（有些复杂查询可以执行相当严重）。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.