东京内阁和京都内阁有什么区别？
FAL Labs拥有多个Tokyo产品和Kyoto产品：
- Tokyo Cabinet和Kyoto Cabinet都是轻量级数据库库。
- Tokyo Tyrant和Kyoto Tycoon都是轻量级数据库服务器...
有人能解释一下Tokyo和Kyoto产品之间的区别吗？
FAL Labs has multiple Tokyo products and Kyoto products:
- Tokyo Cabinet and Kyoto Cabinet are both lightweight database libraries.
- Tokyo Tyrant and Kyoto Tycoon are both lightweight database servers...
Can someone explain the difference between Tokyo and Kyoto products?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
东京内阁更加完整和稳定，京都还太新鲜（今天是2010年12月8日）并且存在一些问题。京都（用 C++ 编写）比东京（用 C 编写）简单得多，但这种简单性存在一些差距。京都的性能比东京差一点，但在线程方面效果更好（至少文档承诺这一点）。
来自官方文档：
<< 2007 年，东京内阁作为 QDBM 的继承者被开发，其目的如下。这些目标已经实现，Tokyo Cabinet 可以取代传统的 DBM 产品。
(...)
2009 年，Kyoto Cabinet 被开发为 QDBM 的另一个继承者。与同类产品（Tokyo Cabinet）相比，追求以下优点。不过Tokyo Cabinet的性能要高于Kyoto Cabinet，至少在单线程操作上是这样。 >>>
我使用了两者，但我仍然更喜欢东京，因为我对京都有疑问： 在使用文件哈希数据库的京都内阁数据库中，如何避免文件大小增加？并且没有人能够帮助我。我仍然不知道如何解决这个问题。
根据我个人的经验，我发现Kyoto更容易编译和安装，也更容易使用。我在东京库依赖性方面遇到了很大的问题，并且在将本机库与 Java 接口链接起来时也遇到了问题。在京都，一切都很好，并且在第一次尝试中工作得很好。但是，正如我之前所说，我感觉使用东京对数据库有更多的控制权。
Tokyo Cabinet is more complete and stable, Kyoto is too fresh yet (today is Dec 8 2010) and has some issues. Kyoto, written in C++, is (much) more simple than Tokyo (written in C), but this simplicity let some gap. The performance of Kyoto is a little bit worse than Tokyo, but works better with threads (at least the documentation promises that).
From the official documentation:
<< In 2007, Tokyo Cabinet was developed as the successor to QDBM on the following purposes. They were achieved and Tokyo Cabinet could replace conventional DBM products.
(...)
In 2009, Kyoto Cabinet was developed as another successor to QDBM. Compared with the sibling product (Tokyo Cabinet), the following advantages were pursued. However, the performance of Tokyo Cabinet is higher than Kyoto Cabinet, at least in single thread operations. >>
I used both, but I still prefer Tokyo, because I had a problem with Kyoto: In Kyoto Cabinet Database using File Hash Database, how can avoid file size increasing? and no one was able to help me. I still don't know how to solve that.
In my personal experience, I found Kyoto easier to compile and install, and also easier to use. I had big problems with Tokyo library dependences and problems to link the native library with the Java interface. With Kyoto everything was good and works fine in the first attempt. But, as I said before, I feel more control over the database using Tokyo.
Tokyo Cabinet 和 Tyrant 是 LGPL，用 C 编写。Kyoto Cabinet 和 Tycoon 是 GPLv3，用 C++ 编写。
京都暴君支持内存中的过期记录，因此可以替代memcached。
开发商表示，京都*并不是东京*的后继者，但这只是一种营销策略；
如果您不打算开发商业产品，请使用京都。它更新更好。
我建议您阅读开发人员的博客（日语和英语]）并仔细阅读头文件（如果您要使用该库）。
祝你好运。
Tokyo Cabinet and Tyrant are LGPL and written in C. Kyoto Cabinet and Tycoon are GPLv3 and written in C++.
Kyoto Tyrant supports expired records in memory, so it can replace memcached.
The developer says Kyoto* isn't successor of Tokyo*, but it's just a marketing strategy;
if you're not gonna develop a commercial product, use Kyoto. It's newer and better.
And I suggest you to read the developer's blog (both Japanese and English]) and read header files carefully (if you're gonna use the library).
Good luck.
就我的用例而言，两者之间最重要的区别是 TC 有“表数据库”，而 KC 没有。
是的，您可以将任意数据序列化为字符串并将其存储为项目值，但是您要么根本无法按值搜索，要么需要迭代整个数据集并反序列化每个项目，要么重新发明轮子并手动索引数据。
Tokyo Cabinet 的 TDB 为嵌套数据（索引、数字和字符串比较，甚至“字段”内的正则表达式）提供了出色的查询功能。京都的东西只是一家KV商店； TC也是一个强大的面向文档的数据库。
The most important difference between the two in regard to my use cases is that TC has a "table database" while KC has not.
Yes, you can serialize arbitrary data to string and store it as item value, but then you either cannot search by value at all, or need to iterate over the whole dataset and deserialize each item, or reinvent the wheel and manually index the data.
Tokyo Cabinet's TDB provides excellent query capabilities for nested data (indexes, numeric and string comparison, even regular expressions within "fields"). The Kyoto thing is just a KV store; TC is also a powerful document-oriented database.
另外，根据我所做的测试，Kyoto 协议仅基于 HTTP - 更加开放，
但比东京的二进制协议慢。
Also, according to test what I did, protocol of Kyoto is only HTTP based - more open,
but slower than binary protocol of Tokyo thing.