问题标签 [memcachedb]

我使用并喜欢伯克利，但一旦你接近一百万左右的条目，它似乎就会陷入困境，尤其是在插入时。我已经尝试过 memcachedb ，但它没有得到维护，所以我担心在生产中使用它。有没有人有任何其他类似的解决方案，基本上我希望能够在一个大型（可能是分布式的）数据集（40+ 百万）上进行关键查找。

注意：任何不是 Java 的东西都是奖励。:-) 今天似乎大多数事情都在走 Java 路线。

我正在构建一个具有以下特征的 webapp：

1. 它只有少量页面，主页，联系我们，关于，singup等。
2. 每个用户都有一个基于 jquery 的页面，允许他们拖放/操作 DOM 元素。
3. 当用户完成对元素的操作后，他们可以点击保存，元素会通过 JSON 发送到服务器上的 PHP 脚本。他们还可以加载以前保存的 JSON。

所以本质上是：很少有页面有 90% 的静态信息。一页有客户端工作，可能有很多 JSON 的 GET/POST。

我已经使用 PHP/Smarty、jQuery 和 mySQL 构建了一个 POC。用户详细信息存储在 mySQL 中，JSON 数据也是如此。网页由 Smarty 缓存在磁盘上。

现在我正在考虑可伸缩性，一个明显的问题是我应该将经常更改的 JSON 数据存储在 mySQL 中，还是应该使用 memcacheDB 或其他键值存储？您会选择简单的 mySQL 选项还是现在引入键值存储，或者您会等着看是否会出现规模问题？我真的会达到 mySQL 成为瓶颈的地步吗？

我打算先在 Slicehost 上托管它，然后在需要时移动它。

反之，它可能是网页浏览量、下载量、投票数等。基本上，不是非常“关键”的数据。

存储这些信息的“最佳”方式是什么？Mysql 不是一个好的选择。你们都用什么？

我想使用 MemcacheDB 而不是 Memcached，因为我没有大量内存用于 Memcached。

它可以与 django 的缓存框架一起使用吗？

还有什么我需要做的吗？

我目前将生成的 HTML 页面存储在 memcached 内存缓存中。这很好用，但是我想增加缓存的存储容量超出可用内存。我真正想要的是：

1. memcached 语义（即不可靠，只是一个缓存）
2. 首选 memcached api（但不是必需的）
3. 大型内存一级缓存 (MRU)
4. 巨大的磁盘二级缓存（主）
5. 使用 LRU 或 LFU 以最大存储空间从磁盘缓存中逐出
6. 经证实的实施

在寻找解决方案时，我找到了以下解决方案，但它们都以某种方式错过了我的标记。有谁知道：

• 我没有考虑过的其他选项
• 一种让 memcachedb 进行驱逐的方法

已经考虑的有：

内存缓存数据库

• 最合适但不驱逐：明确“不是缓存”
• 看不到任何驱逐方式（手动或自动）

图格拉缓存

• 弃了，不支持
• 不想推荐给客户

纳米数据库

• 不使用 memcache api
• 新的和未经证实的
• 不想推荐给客户

我们需要一种缓存解决方案，该解决方案基本上可以根据用户偏好和标准在 3 天到一周的任何时间缓存数据（文本文件）。在这种情况下，基于内存的缓存对我们来说没有意义。我们被提到 MemcacheDB 但是我也想到了一些没有 SQL 的解决方案。

我们当前的应用程序使用 RDMS (MYSQL)，我认为使用 MemcacheDB 是有意义的，但是 NOSQL 确实很有吸引力，因为它即将出现。但是，我们还没有在 NOSQL 下部署生产级应用程序，并且测试版的内容与管理层/投资者的关系并不好。任何你的想法是什么，你将如何解决它？

谢谢你

我研究 NoSQL 已经有一段时间了，但我仍然在努力寻找和过滤结果/文档。

例如，在 NoSQL 世界中，我如何找到两个时间戳内的所有数据？如果一切都存储在键/值的基础上？或者查找一个经纬度点半径范围内的所有文档？

谢谢

我正在尝试构建库应用程序。将 PDF 文档转换为 PNG 图像。（每一页是一个PNG文件）

因此，服务器中将有数百万个 PNG。每秒的点击次数将超过 500 次，我必须为 png 提供服务。

1) 我选择 MemcacheDB 来维护 PNG 2) 我选择 Lightpd 服务器来服务 PNG

问题：1）我是 Lighttpd 的新手，不知道如何根据我想要服务 png 或拒绝访问的参数来验证每个请求。lighttpd 可以使用什么编程语言？2) 我是否为我的要求选择了正确的选项？

我不想争论。谢谢

memcache 有这样的问题吗？

我预计密钥列表的长度约为 1000 左右。

如果这很糟糕，我想知道是否有更好的方法来做到这一点？我认为 memcache 可能足够快，而这样的 O(n) 查询可能不那么重要。例如，我永远不会在 MySQL 中这样做。

谢谢。

由于这是我的第一篇文章，我似乎只能发布 1 个链接，所以我在底部列出了我所指的网站。简而言之，我的目标是让数据库更快地返回结果，我试图包含尽可能多的相关信息，以帮助在帖子底部构建问题。

机器信息

---

但是，我们正在考虑将 mysql 安装移动到集群中具有 256 GB 内存的另一台机器上

表信息

---

我的 MySQL 表看起来像

它有大约 18M 行，有 1M 唯一 cluster_index 和 6K 唯一匹配。我在 PHP 中生成的 sql 查询看起来像。

SQL查询

---

其中 $cluster 包含大约 3,000 个逗号分隔的 cluster_index 的字符串。此查询使用大约 50,000 行，运行大约需要 15 秒，当再次运行相同的查询时，运行大约需要 1 秒。

用法

---

1. 可以假定表格的内容是静态的。
2. 并发用户数量少
3. 上面的查询是当前唯一将在表上运行的查询

子查询

---

基于这篇文章 [stackoverflow: Cache/Re-Use a Subquery in MySQL][1] 和查询时间的改进，我相信我的子查询可以被索引。

根据这篇较早的文章 [Optimizing MySQL: Queries and Indexes][2] in Extra info - 这里看到的不好的是“使用临时”和“使用文件排序”

MySQL 配置信息

---

查询缓存可用，但实际上已关闭，因为大小当前设置为零

基于这篇关于 [Mysql 数据库性能转向][3] 的文章，我认为我需要调整的值是

1. 表缓存
2. key_buffer
3. 排序缓冲区
4. 读取缓冲区大小
5. record_rnd_buffer（用于 GROUP BY 和 ORDER BY 术语）

确定需要改进的领域 - MySQL 查询调整

---

1. 将匹配的数据类型更改为指向另一个表的 int 索引[如果 MySQL 包含可变长度字段（如 TEXT 或 BLOB），MySQL 确实会使用动态行格式，在这种情况下，这意味着需要在磁盘上进行排序. 解决方案不是避开这些数据类型，而是将这些字段拆分为关联表。][4]
2. 索引新的 match_index 字段，以便 GROUP BYmatches发生得更快，基于语句 [“您可能应该为您正在选择、分组、排序或加入的任何字段创建索引。”] [5]

工具

---

调整执行我计划使用

1. [解释][6]参考[输出格式][7]
2. [ab - Apache HTTP 服务器基准测试工具][8]
3. [分析][9] 与 [日志数据][10]

未来的数据库大小

---

目标是构建一个系统，该系统可以有 1M 唯一 cluster_index 值 1M 唯一匹配值，大约 3,000,000,000 表行，对查询的响应时间约为 0.5 秒（我们可以根据需要添加更多内存并在整个集群中分布数据库）

问题

---

1. 我认为我们希望将整个记录集保留在 ram 中，以便查询不会触及磁盘，如果我们将整个数据库保留在 MySQL 缓存中，这是否消除了对 memcachedb 的需要？
2. 试图将整个数据库保存在 MySQL 缓存中是一个糟糕的策略，因为它的设计目的不是持久化吗？像 memcachedb 或 redis 这样的方法会是更好的方法吗，如果是，为什么？
3. 查询完成时，查询创建的临时表“结果”是否会自动销毁？
4. 我们是否应该从 Innodb 切换到 MyISAM [因为它有利于读取大量数据，而 InnoDB 有利于写入大量数据][11]？
5. 我的缓存在我的 [查询缓存配置][12] 中似乎没有设为零，为什么查询当前在我第二次运行时发生得更快？
6. 我可以重组我的查询以消除“使用临时”和“使用文件排序”的发生，我应该使用联接而不是子查询吗？
7. 如何查看 MySQL [Data Cache][13] 的大小？
8. 您建议将值 table_cache、key_buffer、sort_buffer、read_buffer_size、record_rnd_buffer 的大小作为起点？

链接

---

• 1：stackoverflow.com/questions/658937/cache-re-use-a-subquery-in-mysql
• 2：databasejournal.com/features/mysql/article.php/10897_1382791_4/Optimizing-MySQL-Queries-and-Indexes.htm
• 3：debianhelp.co.uk/mysqlperformance.htm
• 4：20bits.com/articles/10-tips-for-optimizing-mysql-queries-that-dont-suck/
• 5：20bits.com/articles/10-tips-for-optimizing-mysql-queries-that-dont-suck/
• 6：dev.mysql.com/doc/refman/5.0/en/explain.html
• 7：dev.mysql.com/doc/refman/5.0/en/explain-output.html
• 8：httpd.apache.org/docs/2.2/programs/ab.html
• 9：mtop.sourceforge.net/
• 10：dev.mysql.com/doc/refman/5.0/en/slow-query-log.html
• 11：20bits.com/articles/10-tips-for-optimizing-mysql-queries-that-dont-suck/
• 12：dev.mysql.com/doc/refman/5.0/en/query-cache-configuration.html
• 13：dev.mysql.com/tech-resources/articles/mysql-query-cache.html