原因 &针对数据库
我与一位同事讨论了我正在编写的程序的架构，我想要更多的意见。
情况：
- 程序应该近乎实时地更新（+/- 1 分钟）。
- 它涉及到物体在坐标系上的运动。
- 有一些事件定期发生（即对象的创建）。
- 动作可以通过用户输入随时改变。
我的解决方案是：
- 构建一个连续运行并在内部存储数据的服务器。
- 服务器定期转储程序状态，以防止电源故障和/或崩溃。
他认为该程序需要一个数据库，我应该使用 cronjobs 来更新数据。我可以通过存储起点、终点和速度来存储运动信息，并通过计算方向和速度来更新 cronjob 中的位置（并计算与其他对象的碰撞）。
他的理由是：
- 需要更多的CPU和资源。内存因为它不断运行。
- 电源故障/崩溃可能会破坏数据。
- 数据库速度更快。
我反对的理由主要是：
- 不太精确，因为事件只能在整分钟发生（不过也不会那么糟糕）。
- 每次运行时都需要将数据从关系数据转换为对象（可能成本高昂）。
- RDBMS 是针对专门问题的通用解决方案，因此专门的解决方案应该更有效。
- 电源故障（或其他崩溃）可能会使数据处于未定义状态，仅部分更新数据，除非采取（可能代价高昂的）预防措施（如事务）。
对此您有何看法？
您可以为任何一方添加哪些论据？
i had a discussion with a coworker about the architecture of a program i'm writing and i'd like some more opinions.
The Situation:
- The Program should update at near-realtime (+/- 1 Minute).
- It involves the movement of objects on a coordinate system.
- There are some events that occur at regular intervals (i.e. creation of the objects).
- Movements can change at any time through user input.
My solution was:
- Build a server that runs continously and stores the data internally.
- The server dumps a state-of-the-program at regular intervals to protect against powerfailures and/or crashes.
He argued that the program requires a Database and i should use cronjobs to update the data. I can store movement information by storing startpoint, endpoint and speed and update the position in the cronjob (and calculate collisions with other objects there) by calculating direction and speed.
His reasons:
- Requires more CPU & Memory because it runs constantly.
- Powerfailures/Crashes might destroy data.
- Databases are faster.
My reasons against this are mostly:
- Not very precise as events can only occur at full minutes (wouldn't be that bad though).
- Requires (possibly costly) transformation of data on every run from relational data to objects.
- RDBMS are a general solution for a specialized problem so a specialized solution should be more efficient.
- Powerfailures (or other crashes) can leave the Data in an undefined state with only partially updated data unless (possibly costly) precautions (like transactions) are taken.
What are your opinions about that?
Which arguments can you add for any side?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
数据库并不更快。多么愚蠢...数据库怎么能比编写自定义数据结构并将其存储在内存中更快呢？数据库是为您将数据保存到磁盘的通用工具，因此您不必自己编写所有代码来执行此操作。因为它们必须满足众多不同（有时不一致）业务功能（持久性（持久性）、事务完整性、缓存、关系完整性、原子性等）的需求，并以一种保护应用程序开发人员免受影响的方式来实现。不必如此担心，根据定义，它会变慢。但这并不一定意味着他的结论是错误的。
他的每个其他反对意见都可以通过自己编写代码来解决该问题来解决...但是您知道这是怎么回事...在某些时候，编写自定义代码来解决重要问题的开发工作您的应用程序超过了仅使用数据库对性能的影响 - 数据库已经完成了开箱即用的所有操作...这些问题中有多少是重要的？您知道如何编写解决这些问题所需的代码吗？
Databases are not faster. How silly... How can a database be faster than writing a custom data structure and storing it in memory ?? Databases are Generalized tools to persist data to disk for you so you don't have to write all the code to do that yourself. Because they have to address the needs of numerous disparate (and sometimes inconsistent) business functions (Persistency (Durability), Transactional integrity, caching, relational integrity, atomicity, etc. etc. ) and do it in a way that protects the application developer from having to worry about it so much, by definition it is going to be slower. That doesn't necessarilly mean his conclusion is wrong however.
Each of his other objections can be addressed by writing the code to address that issue yourself... But you see where that is going... At some point, the development efforts of writing the custom code to address the issues that are important for your application outweigh the performance hit of just using a database - which already does all that stuff out of the box... How many of these issues are important ? and do you know how to write the code necessary to address them ?
从您在这里所描述的内容来看，我想说您的解决方案似乎确实是更好的选择。你说它每分钟运行一次，但是运行需要多长时间？如果只有几秒钟，那么到关系数据的转换可能是无关紧要的，任何其他开销也是如此。其中大部分可能需要 30 秒。这再次假设该程序非常小。
但是，如果它更大，并且假设它会变得更大，那么直接转储是更好的方法。您可能不想每次运行都进行完整转储，但这取决于您，只需记住它最终可能会占用大量空间（如果您使用数据库，情况也是如此）。
如果你要放弃状态，你需要有某种冗余系统以及准交易。您可能需要存储多个副本，以防最新版本出现问题。比如说，在您存储数据时断电了，除了写了一半的备份之外，您没有任何备份。事务，您需要一些东西来告诉文件已完全写入，因此如果出现问题，您始终可以知道最近成功的保存是什么。
哦，对于他关于它不断运行的论点：如果你将它设置为一个 cronjob，甚至是一个自封闭的睡眠语句或类似的，它在不运行时不会使用任何 CPU 时间，与它运行时的数量相同如果您使用的是 RDBMS。
如果您直接写入磁盘，那么这将是比数据库更快的方法，并且检索速度更快，因为正如您所指出的，没有开销。
摘要： 如果您有大量空闲处理器时间或历史记录，那么数据库是一个好主意，但如果资源是合理的关注点，那么它可能会变得太大的开销，并且采取预防措施的转储更好。
From what you've described here, I'd say your solution does seem to be the better option. You say it runs once a minute, but how long does it take to run? If only a few seconds, then the transformation to relational data would likely be inconsequential, as would any other overhead. most of this would take likely 30 seconds. This is assuming, again, that the program is quite small.
However, if it is larger, and assuming that it will get larger, doing a straight dump is a better method. You might not want to do a full dump every run, but that's up to you, just remember that it could wind up taking a lot of space (same goes if you're using a database).
If you're going to dump the state, you would need to have some sort of a redundancy system in place, along with quasi-transactions. You would want to store several copies, in case something happens to the newest version. Say, the power goes out while you're storing, and you have no backups beyond this half-written one. Transactions, you would need something to tell that the file has been fully written, so if something does go wrong, you can always tell what the most recent successful save was.
Oh, and for his argument of it running constantly: if you have it set to a cronjob, or even a self-enclosed sleep statement or similar, it doesn't use any CPU time when it's not running, the same amount that it would if you're using an RDBMS.
If you're writing straight to disk, then this will be the faster method over a database, and faster retrieval, since, as you pointed out, there is no overhead.
Summary: A database is a good idea if you have a lot of idle processor time or historical records, but if resources are a legitimate concern, then it can become too much overhead and a dump with precautions taken is better.
mySQL 现在可以对空间数据建模。
http://dev.mysql.com/doc/refman/ 4.1/en/gis-introduction.html
http ://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html
您可以使用数据库来跟踪世界位置、用户位置、项目位置等。
mySQL can now model spatial data.
http://dev.mysql.com/doc/refman/4.1/en/gis-introduction.html
http://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html
You could use the database to keep track of world locations, user locations, items locations ect.