问题标签 [tokyo-cabinet]

我有 2 台服务器在集群中运行东京机柜（2 个硬盘驱动器，因此 4 个东京机柜实例）。如果它只是东京内阁的一个实例，那么使用 php memcache 协议进行通信是相当直接的。我的问题是如果它是集群，你如何连接 php？

选项 1： $memcache->connect('memcache_host', 11211); 使用此选项，您只能连接到东京机柜的实例。

选项 2: $memcache = new Memcache; $memcache->addServer('memcache_host', 11211); $memcache->addServer('memcache_host2', 11211); 使用这个，你可以连接多个，但是数据是否正确存储在集群中？

谢谢！

我已经在 RDBMS 领域工作多年，但希望探索整个 nosql 运动。所以这是我的第一个问题：

有重复键的可能性是不好的做法吗？例如，一个以姓氏为键的地址簿（很可能是搜索项？）可能有多个实体。那么使用姓氏是不好的做法吗？键应该是实体的最“可搜索”的定义吗？在这个全新的世界中（对我而言），是否有任何“最佳实践”资源？

我对东京内阁（特别是 tc 界面）很感兴趣，但不知道如何遍历具有相同密钥的不同实体（例如，见上文）。我只能得到第一个实体。无论如何，提前感谢您的帮助

我们正在着手构建一个在线平台（API、服务器、数据、Wahoo！）。对于上下文，假设我们需要构建类似 twitter 的东西，但评论（推文）是围绕现场活动组织的。有关实时事件本身的信息必须尽可能快且一致地交付给客户，而有关事件的评论可能需要等待更长的时间才能交付。现场活动结束后，我们将阅读大量内容。

可扩展性非常重要。我们想从租用 VPS 切片开始，并从那里扩展。我是云的忠实粉丝，并希望尽可能长时间地呆在那里。我们可能会使用红宝石。

我确信我想尝试使用文档存储而不是 RDBMS。我喜欢无模式存储的想法以及通过关注键值来更容易扩展的承诺。

问题是我不知道哪种技术最适合我们的平台。我查看了 Couch、Mongo、Tokyo Cabinet、Cassandra 和带有斑点文档的 RDBMS。为这项特定工作选择合适的工具有什么帮助吗？

我想知道东京暴君指数的大小要求。

如果我在字段上有一个索引并只x插入一个包含字段的记录，那么索引会增长吗？另外：在这种情况下插入时间会增加吗？yzx

我想在运行查询之前确定东京内阁表上的查询将返回的记录数。我使用 rufus-tokyo Ruby gem 作为我的界面。做这个的最好方式是什么？

我正在使用 Ruby 官方 Ruby C 接口，但无法进行 bzip 工作。它确实在 bzip 支持下构建，./configure 说：

所以我编写了这个示例程序，它只向两个文件写入一个条目，一个应该是 bzip'd，一个不是。两者都没有被压缩；除了最后的简单文件大小测试之外，我还可以编辑 with_bzip.tcb 文件并在那里查看原始字符串文本。

更糟糕的是，如果我尝试使用 Oklahoma Mixer 的预览版（以下示例 - 尽管我没有添加新标签的声誉），它的压缩效果很好。当我在它的 try() 调用中加入一些调试时，它似乎正在对 tune(0, 0, 0, -1, -1, 4) 进行相同的调用。我完全被难住了——谁能告诉我我上面的代码做错了什么？

我在 Rack 上的 Sinatra 中构建了一个非常简单的 REST 服务。它由 3 个 Tokyo Cabinet/Table 数据存储提供支持，这些数据存储具有需要打开和关闭的连接。我有两个直接用 Ruby 编写的模型类，目前它们只是简单地连接、获取或放置他们需要的东西，然后断开连接。显然，这不会长期有效。

我也有一些 Rack 中间件，比如 Warden，它们依赖于这些模型类。

管理打开和关闭连接的最佳方法是什么？据我所知，Rack 不提供启动/关闭挂钩。我曾考虑在 env 中插入一个提供对 TC/TT 对象的引用的中间件，但随后我必须通过 Sinatra 将其通过管道传递给模型，这似乎也没有效率；这只会是与 TC 的按请求连接。我想每个服务器实例生命周期将是一个更合适的生命周期。

谢谢！

这可能吗？我在任何地方都找不到答案。

基本上，我正在查看一个设置，其中我有多个工人（盒子），它们最终必须将所有数据都存储到东京内阁索引/数据库中（我在 memcached 协议上使用 Tokyto Tyrant。这并不重要，但仍然如此）

基本上，我尝试将数据直接推送到另一个运行 Tokyo Tyrant 的盒子，但一段时间后 TT 无法处理它。插入变得非常慢，工作人员坐在那里闲着想​​将数据卸载到 TT 服务器。（我尝试了各种方法来提高性能，更多的内存、raid-configs、盒子上的多个 TT 服务器等）但性能（插入/秒）的主要下降迟早会出现。

现在，我正在考虑让每个工人将自己的数据存储在本地东京暴君数据库中的选项，然后合并所有工人的数据库（保证没有重复的密钥）

任何帮助表示赞赏，（还有其他在 TT 上分配负载的方法表示赞赏）

顺便说一句：TT 的配置：#bnum=20000000#opts=l#xmsiz=162000000 我将 bnum 设置为预期项目的上限：2000 万。

谢谢， Geert-Jan

有问题的图书馆是东京内阁。

我希望将本机库、JNI 库和所有 Java API 类放在一个 JAR 文件中，以避免重新分发的麻烦。

在 GitHub 上似乎有一个尝试，但是

1. 它不包括实际的本机库，仅包括 JNI 库。
2. 它似乎特定于Leiningen的本机依赖项插件（它不能作为可再发行组件工作）。

问题是，我可以将所有内容捆绑在一个 JAR 中并重新分发吗？如果是，如何？

PS：是的，我意识到它可能会影响可移植性。

有人可以参考东京内阁和东京暴君的好教程吗