缩放写强化应用程序（LAMP，MySQL）（目录样式应用程序）

我想知道是否有人因为文件导入而在写入密集型数据方面有经验。缩放写强化应用程序（LAMP，MySQL）（目录样式应用程序）

主要要求是业务用户能够导入表示主表之间关系的数据。他们应该能够实时导出（尽可能）。

设置：

前端（PHP）应用程序写入主数据库上。
复制设置 - 主数据库被复制到两个SLAVE数据库服务器。
SLAVE服务器之一被用作前端UI交互（重度查询）的“读取”数据库。
同一SLAVE服务器也用于基于在前端预览过的查询“导出”数据。（很多JOIN表）。

主要的挑战是复制日志。即使他们已经导入的文件已经被处理，用户也不满意前端数据不可用的性能&。复制LAG是罪魁祸首。

转向NoSQL即LONG Term的目标。现在仍然想改善性能。顺便说一句，该应用程序在内部使用，但托管在一个知名的托管公司。用户数量约为150个用户。

导入的数据大约是200k-800k行。每行代表一行。

任何投入，将不胜感激:)

来源

2010-08-04 rmartinez

你有没有调查为什么滞后发生，我不知道实际是什么滞后？ – Wrikken 2010-08-04 16:13:01

为什么要将“NoSQL”作为长期目标？（完全披露，我对“NoSQL”这个词提出质疑 - 拥有可与许多数据库一起使用的标准化查询语言有什么问题？我可以欣赏那些希望为Web应用程序开发和其他用途提供更灵活的数据库的人，但问题在于，恕我直言，并不是数据库支持SQL这一事实 - 数据库的性能，建模和完整性特征非常重要）你认为你可以在非关系数据库中更有效地建模数据？ – 2010-08-05 13:38:48

对于性能和可伸缩性，我们已将NoSQL（即MongoDB）视为我们的LONG术语路径。我们的数据非常简单，可以在非关系数据库中建模。数据量和数据可用性要求并不简单。 – rmartinez 2010-08-06 02:54:41

@Wrikken，

（通过回答框接听）

是，许多 “刀片” 和更新的。该应用程序利用临时表（即具有某些前缀的实际物理表）来插入初步数据。并做了很多INSERT INTO .. SELECT * FROM ..

这导致大量语句被复制到最终临时表被删除的SLAVE中。我已经建议这样的类型表应该从要复制的表列表中排除，而不是使用INSERT INTO ... SELECT * FROM应用程序应该只是从应用程序上的构建INSERT，UPDATE，DELETE语句中选择一切内存空间并执行SQL语句。它应该减少被复制的临时表相关语句的数量。

来源

2010-08-05 00:07:12 rmartinez

有很多因素在提高MySQL复制滞后性方面发挥作用。也许这播客约在Youtube上的MySQL复制通过他们的DBA可能会为您提供一些提示&指针：

http://itc.conversationsnetwork.org/shows/detail3299.html

希望这有助于。

来源

2010-08-05 06:38:39

感谢Bug磁铁。我会检查这一个。 – rmartinez 2010-08-05 09:35:47

缩放写强化应用程序（LAMP，MySQL）（目录样式应用程序）

回答

相关问题