wildcards - relational database




使用NoSQL数据存储时遇到了哪些可伸缩性问题? (10)

NoSQL指的是与关系数据库和ACID保证的历史相关的非关系数据存储。 流行的开源NoSQL数据存储包括:

  • Cassandra (表格,用Java编写,由思科,WebEx,Digg,Facebook,IBM,Mahalo,Rackspace,Reddit和Twitter使用)
  • CouchDB (文档,用Erlang编写,由BBC和Engine Yard使用)
  • Dynomite (键值,用Erlang编写,由Powerset使用)
  • HBase (键值,用Java编写,由Bing使用)
  • Hypertable (表格,用C ++编写,百度使用)
  • Kai (键值,用Erlang编写)
  • MemcacheDB (键值,用C语言编写,由Reddit使用)
  • MongoDB (文档,用C ++编写,由Electronic Arts,Github,NY Times和Sourceforge使用)
  • Neo4j (图形,用Java编写,由瑞典一些大学使用)
  • Project Voldemort (由Java编写的关键值,由LinkedIn使用)
  • Redis (键值,由C语言编写,由Craigslist,Engine Yard和Github使用)
  • Riak (关键值,用Comcast和Mochi Media使用的Erlang编写)
  • Ringo (键值,由Erlang编写,由Nokia使用)
  • Scalaris (关键值,用Erlang编写,由OnScale使用)
  • Terrastore (文档,用Java编写)
  • ThruDB (文档,用C ++编写,由JunkDepot.com使用)
  • 东京内阁/东京暴君 (键值,用C语言编写,由Mixi.jp(日本社交网站)使用)

我想知道您 - SO读者 - 使用数据存储和您使用的NoSQL数据存储解决的具体问题。

问题:

  • 您使用NoSQL数据存储解决了哪些可伸缩性问题?
  • 您使用了哪些NoSQL数据存储?
  • 在切换到NoSQL数据存储之前,您使用了哪个数据库?

我正在寻找第一手经验,所以请不要回答,除非你有这个经验。


托德霍夫highscalability.com有很多关于NoSQL的广泛报道,包括一些案例研究。

商用Vertica列式DBMS可能适合您的目的(即使它支持SQL):与用于分析查询的传统关系DBMS相比,它非常快速。 参见Stonebraker等人最近的CACM论文将Vertica与map-reduce进行对比。

更新: Twitter选择了Cassandra ,其中包括HBase,Voldemort,MongoDB,MemcacheDB,Redis和HyperTable。

更新2:Rick Cattell刚刚发布了高性能数据存储中的几个NoSQL系统的比较。 而highscalability.com对瑞克的论文的看法就在here


我不。 我想要使​​用一个简单且免费的键值存储,我可以在这个过程中调用,但这种情况在Windows平台上不存在。 现在我使用Sqlite,但我想使用像东京内阁这样的东西。 BerkeleyDB拥有许可“问题”。

但是,如果你想使用Windows操作系统,你选择的NoSQL数据库是有限的。 并不总是一个C#提供者

我尝试过使用MongoDB,它比Sqlite快40倍,所以也许我应该使用它。 但我仍然希望有一个简单的在线解决方案。


我们将我们用于存储在Postgresql和Memcached中的一些数据移入Redis 。 关键值存储更适合存储分层对象数据。 与使用ORM将Blob映射到RDBMS相比,您可以更快地存储Blob数据,并且开发时间和工作量要少得多。

我有一个开源的c#redis客户端 ,可以让你存储和检索任何1行POCO对象:

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

主要价值商店也更容易“扩展”,因为您可以添加新服务器,然后平均分配负载以包含新服务器。 重要的是,没有中央服务器会限制您的可扩展性。 (尽管你仍然需要一致的散列策略来分发你的请求)。

我认为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);

我们将部分数据从mysql移动到mongodb,而不是用于可伸缩性,但更多的是因为它更适合于文件和非表格数据。

我们目前在生产中存储:

  • 2.5万个文件(60GB)
  • 1.3亿个其他“文件”(350GB)

每日营业额约10GB。

该数据库使用mongodb python api(pymongo)在两个节点(6x450GB sas raid10)上与apache / wsgi / python客户端进行“配对”配置。 磁盘设置可能是矫枉过正,但这就是我们用于mysql的。

除了pomongo线程池的一些问题和mongodb服务器的阻塞性质之外,它是一个很好的体验。


我会鼓励任何人阅读这个,现在再次尝试Couchbase 3.0已经出来了。 初学者有超过200种新功能。 Couchbase Server的性能,可用性,可扩展性和易管理功能使其成为一个非常灵活,高度可用的数据库。 管理UI是内置的,API会自动发现集群节点,因此不需要从应用程序到数据库的负载平衡器。 虽然我们目前没有托管服务,但您可以在AWS,RedHat Gears,Cloudera,Rackspace,CloudStorage等Docker容器上运行couchbase。 关于重新平衡取决于您指的是什么,但Couchbase在节点故障后不会根据设计自动重新平衡,但是管理员可以为第一个节点故障设置自动故障转移并使用我们的API,您还可以访问在使它们处于活动状态或使用RestAPI之前,可以使用副本vbuckets进行读取,您可以通过监视工具强制执行故障转移。 这是一个特殊情况,但可以完成。

除非节点完全脱机并且永不再回来或者新节点准备好自动平衡,否则我们往往不会重新平衡任何模式。 这里有几个指南可以帮助任何有兴趣看到性能最好的NoSQL数据库是什么的人。

  1. Couchbase Server 3.0
  2. 管理指南
  3. REST API
  4. 开发者指南

最后,我还鼓励你查看N1QL的分布式查询:

  1. N1QL教程
  2. N1QL指南

感谢您阅读并让我或其他人知道您是否需要更多帮助!

奥斯汀


我使用redis在机器上存储日志消息。 这很容易实施,而且非常有用。 Redis真的很有趣


我已经将一个小的子项目从MySQL切换到CouchDB,以便能够处理负载。 结果是惊人的。

大约两年前,我们在http://www.ubuntuusers.de/上发布了一个自行编写的软件(这可能是德国最大的Linux社区网站)。 该网站是用Python编写的,我们添加了一个WSGI中间件,它能够捕获所有异常并将它们发送到另一个小型的MySQL网站。 这个小网站使用散列来确定不同的错误,并存储发生次数和最后一次发生的次数。

不幸的是,在发布后不久,traceback-logger网站不再响应。 我们的主站点的生产数据库有一些锁定问题,几乎每个请求都会抛出异常,还有几个其他的错误,这些错误在测试阶段我们还没有探索过。 我们主站点的服务器集群称为traceback-logger提交页面,每秒几次。 对于托管追踪记录器的小型服务器来说,这太过分了(它已经是一台旧服务器,仅用于开发目的)。

此时CouchDB非常流行,所以我决定尝试一下,然后写一个小的跟踪记录器。 新的记录器只包含一个python文件,该文件提供了一个包含排序和筛选选项的缺陷列表以及一个提交页面。 在后台我开始了一个CouchDB过程。 新软件对所有请求的反应非常迅速,我们能够查看大量的自动错误报告。

一个有趣的事情是,之前的解决方案是在旧的专用服务器上运行,另一方面,新的基于CouchDB的站点只运行在资源非常有限的共享xen实例上。 而且我甚至没有使用键值存储的实力来横向扩展。 CouchDB / Erlang OTP处理并发请求而不锁定任何内容的能力已足以满足需求。

现在,快速编写的CouchDB-traceback记录器仍在运行,并且是探索主网站上的错误的有效方法。 无论如何,大约每月一次的数据库变得太大,CouchDB进程被杀死。 但是,然后,CouchDB的compact-db命令再次将数GB的大小从几GB减少到一些KB,并且数据库重新启动并运行(也许我应该考虑在其中添加一个cronjob ... 0o)。

总之,对于这个子项目,CouchDB肯定是最好的选择(或者至少比MySQL更好的选择),并且它的工作很好。


我没有第一手经验,但我发现this博客条目很有趣。


我过去曾经使用Couchbase,并且遇到了重新平衡问题和其他问题。 目前,我在几个生产项目中使用Redis。 我正在使用redislabs.com ,它是Redis的托管服务,负责扩展您的Redis集群。 我在http://thomasjaeger.wordpress.com上的博客上发布了一个关于对象持久性的视频,演示了如何在提供者模型中使用Redis,以及如何将C#对象存储到Redis中。 看一看。


由于我没有任何第一手经验,所以我对你的粗体文本感到抱歉,但这组博客文章是解决CouchDB问题的一个很好的例子。

CouchDB:案例研究

基本上, textme应用程序使用CouchDB来处理它们爆炸的数据问题。 他们发现SQL太慢无法处理大量的档案数据,并将其移至CouchDB。 这是一个很好的阅读,他讨论了计算CouchDB可以解决什么问题以及他们如何解决它们的整个过程。







distributed-database