【发布时间】:2012-04-07 05:21:55
【问题描述】:
我正在设计一个可能保持小于 100 MB、拥有自己的服务器并且将通过 Intranet Java EE Web 应用程序读取和修改的基础。我找到了很多关于优化大型基础的参考资料,我知道这是一个更关键的问题,但我有很多时间,读取/插入速度是项目的优先事项,我很确定我可以以某种方式利用如此小的总数据库大小。当然,除非 MySQL 已经自然地针对这种小型基准进行了优化。
当然,它确实适合内存,但我需要将其数据实际保存在磁盘上,或者至少在不久之后将其保存到磁盘;我想到了一些听起来很疯狂的替代方案,例如在第一次需要时(可能是在用户连接时?)按顺序将整个基础加载到内存中,然后以某种方式将其提交到磁盘。
但我认为最好在这里问一下,看看是否有人以前遇到过这种情况,并且有一个从小规模获利的好主意。
我更多地考虑数据库访问而不是结构,但如果有人有针对小型基础的结构设计技巧并认为他们使访问优化问题完全无关紧要,说明这可能是适当的回应。
提前致谢。
编辑:这个应用程序有点关键,在我完成后它将由最习惯 MySQL 的人开发,所以不同的 DBMS 不是一个很好的选择,除非它们与 MySQL 非常相似.
【问题讨论】:
-
只要确保 mysql 的缓存设置为大于 db 的大小,当您在表上工作时它会自然地将自己缓存在内存中。
-
我已经想到了,但不确定它会以这种方式工作。看起来很顺利,我很确定我会这样做。谢谢!
-
您真的遇到了性能问题吗?看来您可能正在尝试过早优化。首先,实现应用程序,然后对其进行基准测试,如果基准测试显示严重瓶颈,则最后对其进行优化。
-
我没有遇到性能问题,这是关于最佳实践的。我想知道是否存在设计小型数据库的最佳方法,即考虑到它们的大小;如果以这种优化的方式进行不会产生任何额外的开发时间或成本,那么就没有理由以非优化的方式开发解决方案。当然,这不太可能对我的项目产生太大影响,但是如果这个问题得到了一个零成本的解决方案,并且这个站点中的每个人都开始用它优化他们的小型数据库,也许我们会在全球范围内节省一些处理 lol
标签: mysql database relational-database