MySQL-Memcached or NOSQL Tokyo Tyrant.doc

MySQL-Memcached or NOSQL Tokyo Tyrant 使用配合内存缓存技术的数据库还是使用非数据库的Tokyo Tyrant? 人们常常是被迫的在使用数据库，如MYSQL， 而不去考虑它是否是针对自己问题最好的解决办法。 为什么呢？ 因为其他的应用程序都在使用它，那么这个新的应用程序为什么不去用呢？在过去的几个月里，我为使用自己数据库的客户做了大量的工作，他们大多使用内存缓存技术。基于关键字来查找一条记录，更新行中的数据，把行中的数据写回数据库。删掉然后重复。 确认这些调整不断的变化，通过用户名来查找很小的计数。但它们中的大部分都设计的很简单。 一个典型的例子就是一款简单的在线游戏。这个在线游戏可能只需要应用程序从数据库中读取一条记录。这条记录可能包含了所有对这个游戏很重要的数据，要更新并把记录写回到数据库。你可能会惊讶于有多少人在用这种系统，像我就会频繁的接触到这类应用程序。保持简单，确保应用程序功能完整、结构精简，并运行良好就可以。但是，问题就在于，如此简单的设计，当数据增大后也会开始出现问题，你的内存将不够用。那有没有一个更好的架构呢？有办法使你在数据库之外更具有扩展性吗？甚至说数据库是否是存储这些数据的最理想的位置呢？ 我决定安装一些我曾经见到很多客户使用的那样，很简单的应用程序，用这些应用程序我可以比较MYSQL与MYSQL使用内存缓存技术，然后再与其他解决方案做个对比，如Tokyo Tyrant或者cassandra 我的应用程序做以下操作： A) 从数据库中读取一行以数字为主键的数据。 B) 更新那一行的数据并替换在磁盘中的内容 C) 在从得到的数据中，来查找另外一个表中以字段为关键字的数据（我们来查邮件地址） 看起来很简单吧？我的两个表，每个表有5兆行的数据，让我们看看发生了什么： 你能看到当我的数据在用尽内存后的性能急剧下降。那并不是酷，是吧？毕竟数据的规模一直是增长的，只有很少的回缩。这就令每个人都面临一个挑战，就是面临不断增加的数据的规模，怎样来维护应用程序的性能。 这是令人们开始头疼的地方了。他们很自然的认定他们需要扩大规模，就需要更多的内存！如果性能不好，那我们就必须要更多的内存。所以出现了更大的内存（盒子），只读（存储器），复杂的碎片系统，关于聚集的讨论，更多的内存缓存技术。 我们需要弥补数据库的无效率性来保证我们应用程序的扩展性。 对于一些应用程序的问题，我们只解决了表面现象，而不是问题的本身。不论你怎样想去适应，有些事情是无法适应的（就像教父3---一部经典电影中---说的）。问题在于人们假定数据的存储一定要储存在数据库中。“它是数据，它需要到数据库中。”这是争论中常常提出的。但是请您扶好帽子，我要让您大吃一惊了。对于一些应用程序，把数据放进数据库是非常愚蠢的。是的， 博客的主人写了一篇名为mysqlperformanceblog的日志，说你可能不想再用数据库了。我知道这是多么的另类！但是我们中的许多人已经接受了将数据（至少是暂时的）存储在数据库之外。 想想内存缓存技术吧。 几乎每个人都喜欢用内存缓存技术，它工作简单、快速并且好用。当你的数据集超越内存的界限或者数据库很简单不用再保存更多的东西，这种方法真的可以提升性能。我知道你正在想，我简单的关键字查询可以从缓存技术中获益。那么让我们试试吧！我就用刚创建的简单应用程序来读取两行数据，并且如果允许，更新从内存缓存中读取的一行，删去更新过的，并且只用当需要的时候才从数据库中进行读取。我测试了当内存缓存的尺寸为1GB,2GB,4GB时的情况。对这些测试我留256M的缓冲池，或者说大概总数据的9%在内存中。 我们来看看内存缓存设为1GB时： 什么，性能减退了？但我们用了更多的内存呀！！怎么会这样！ 内存缓存不是彻底的办法。我和许多客户谈过，他们说“我们将会使用缓存技术”。 一个应用程序，有时会表现的很好以至令人尖叫，而其他时候不会。而且，为达到成功，其他应用程序要求更多的内存被分配为内存缓存，。 这个应用程序在1到2，000，000间随机选取数字，并用这个数作为关键字来进行查询。然后从那些随机选取的行的数据中，来查找第二条以邮件地址做关键字的信息。因为整个数据集大概有4GB但是只有1G在缓存中，我需要不断地清理缓存中的数据来为从数据库中读到的新记录来腾出地方。 记住，内存缓存技术需要不断地重复来提供帮助。我的确可以不断得到一个固定的在缓存中的命中次数。但是在MYSQL中写的次数以及仍旧很大的读的次数决定了它的花费。我发现另外一个令客户的应用程序死掉的地方是，在应用程序中做了一些有序扫描却没有足够的内存做缓存。例如，如果有1，000，000行数据，但是内存最多存储500，000