担心新站点的可扩展性
我正在构建一个具有以下特征的网络应用程序：
- 它只有少量页面，主页，联系我们，关于，singup等。
- 每个用户都有一个基于 jquery 的页面，允许他们拖/放/操作 DOM 元素。
- 当用户完成元素操作后，他们可以点击“保存”，元素将通过 JSON 发送到服务器上的 PHP 脚本。他们还可以加载以前保存的 JSON。
本质上来说：只有很少的页面包含 90% 的静态信息。一页包含客户端工作，并且可能包含大量 JSON GETting/POSTing。
我使用 PHP/Smarty、jQuery 和 mySQL 构建了一个 POC。用户详细信息存储在 mySQL 中，JSON 数据也是如此。网页由 Smarty 缓存在磁盘上。
现在我正在考虑可扩展性，一个明显的问题是我应该将经常更改的 JSON 数据存储在 mySQL 中，还是应该使用 memcacheDB 或其他一些键值存储？您会选择简单的 mySQL 选项还是立即引入键值存储，还是会等待看看是否会出现规模问题？我真的会达到 mySQL 成为瓶颈的地步吗？
我计划首先将其托管在 Slicehost 上，然后在需要时将其移动。
I am building a webapp that has the following characteristics:
- It only has a small number of pages, home,contact us, about,singup,etc.
- Each user has one jquery-based page that allows them to drag/drop/manipulate DOM elements.
- When a user has finished manipulating elements they can hit Save and elements are sent via JSON to a PHP script on the server. They can also Load previously saved JSON.
So essentially: very few pages with 90% static information. One page with client-side work and potentially a lot of GETting/POSTing of JSON.
I have built a POC of this using PHP/Smarty, jQuery and mySQL. User details are stored in mySQL and so is the JSON data. Webpages are cached by Smarty on disk.
Now I'm thinking about scalability and the obvious question is should I be storing the often-changed JSON data in mySQL or should I be using memcacheDB or some other key-value store? Would you go for the easy mySQL option or introduce a key-value store now or would you wait to see if scale issue arise? Am I realistically ever going to reach a point where mySQL is the bottleneck?
I'm planning to host this on Slicehost to begin with and then move it if need be.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题是，是否会根据这些值进行任何查找？是否会在数据库级别更新特定值...如果您所做的只是提取整个字符串并且不需要查询或修改，则序列化数据或 json 将更快、更高效（存储方面）它。
根据您的扩展方式，您可能希望保留键/值结构以及用于查找目的的平面数据表示。
还可以考虑使用 apache AB 进行一些基准测试，并了解您的更改如何影响并发输出。
祝你好运 ：）
Question is, would there be any lookups based on these values or not? Is there going to be updates for specific values at database level or not... Serilaized data or json is going to be faster and more efficient(storage wise) if all you do is pull the entire string and have no requirements to query or modify it.
Based on how you scale though, you may want to keep a key/value structure along with a flat data representation for lookup purpose.
Also consider using apache AB for some benchmarking and getting ideas on how your changes effect your concurrent output.
Good luck :)
就 JSON 而言，它不会产生任何影响：我不知道如何优化该数据的存储。我认为问题归结为“用户数据有多复杂？”。如果有一个与 RDBMS 外键相关的大量社交图，并且将该数据映射到键值存储太困难，我宁愿现在不花精力。但是，如果用户数据只是平面配置文件信息，我宁愿现在就迁移到键值存储，而不是稍后，在我使用太多 RDBMS 功能之前。
As far as the JSON is concerned, it won't make a difference: I don't see how you can optimize the storage of that data. I think the question boils down to "How complex is the user data?". If there's a massive social graph connected with RDBMS foreign keys, and it's too difficult to map that data to a key-value store, I'd rather not expend the effort now. However, if the user data is just flat profile information, I'd rather move to a key-value store now, than later, before I use too many RDBMS features.