我的目标是创建一款浏览器游戏，玩家可以在其中建造建筑物。
每栋建筑都有几个模块（发动机、办公室、生产线……）。每个模块最终都会运行一个或多个操作，例如使用成分 Y、Z 创建 2OO 个“项目 X”。
游戏服务器将使用 erlang 进行设置：一个 OTP 应用程序作为服务器本身，氮作为 Web 前端。
我需要数据的持久性。我在考虑以下内容：
当某人或某物与建筑物交互时，或者代表某些生产线的计时器结束时，主管会生成一个 gen_server （如果尚未生成），它从数据库加载建筑物的状态，因此gen_server 可以回答诸如“添加此模块”、“启动此操作”、“将此产品存储到仓库”、“死亡”等消息。（
但是当建筑物在 X 秒或分钟内没有收到任何消息时，他会终止（由于 gen_server 超时功能）并将其当前状态返回到数据库，
因此，由于这将是一个（软）实时游戏，因此 gen_server 必须设置得非常快，我认为 membase 作为数据库。因为众所周知它有很好的响应时间
我的问题是：当gen服务器启动运行时，他的状态会填充一些内存，并且这个状态也存在于membase处理的内存中，所以这state 在内存中使用两倍大小，这是一个糟糕的设计吗
？使用 mnesia 是更好的选择还是其他？
我担心 mnesia 2 Go（或 4？）表大小限制，因为我目前不知道我的 gen_servers 的平均状态大小（本例中的建筑物，还有玩家、生产线等），并且有一天我可能会超过1 位玩家 :)
谢谢
I aim to create a browser game where players can set up buildings.
Each building will have several modules (engines, offices,production lines, ...). Each module will have enentually one or more actions running, like creation of 2OO 'item X' with ingredients Y, Z.
The game server will be set up with erlang : An OTP application as the server itself, and nitrogen as the web front.
I need persistence of data. I was thinking about the following :
When somebody or something interacts with a building, or a timer representing some production line ends up, a supervisor spawns a gen_server (if not already spawned) which loads the state of the building from a database, so the gen_server can answer messages like 'add this module', 'starts this action', 'store this production to warehouse', 'die', etc. (
But when a building don't receive any messages during X seconds or minutes, he will terminate (thanks to the gen_server timeout feature) and drop its current state back to the database.
So, as it will be a (soft) real time game, the gen_server must be set up very fastly. I was thinking of membase as the database, because it's known to have very good response time.
My question is : when a gen server is up an running, his states fills some memory, and this state is present in the memory handled by membase too, so the state use two times his size in memory. Is that a bad design ?
Is membase a good solution to handle persistence in my case ? would be use mnesia a better choice , or something else ?
I fear mnesia 2 Go (or 4 ?) table size limit because i don't know at the moment the average state size of my gen_servers (buildings in this example, butalso players, production lines, whatever) and i may have someday more than 1 player :)
Thank you
发布评论
评论（2）
我同意 Hynek-Pichi-Vychodil 的观点。 Riak 对于键值存储来说是一个很棒的东西。
我们几乎 95% 都使用 Riak 来完成您所描述的同样的事情。到目前为止一切正常，没有任何问题。如果您遇到 Riak 的性能限制 - 添加更多节点就可以了！
Riak 的另一个很酷的事情是它随着时间的推移性能下降非常低。您可以在此处找到有关 Riak 基准测试的更多信息：http: //joyeur.com/2010/10/31/riak-smartmachine-benchmark-the-technical-details/
如果您同意：
关于membase和内存使用: 我也尝试过 membase，但是我发现它不适合我的任务 - （membase 声明容错，但我无法以它应该处理错误的方式设置它，即使在 membase 人员的帮助下我也没有成功）。因此，目前我使用以下架构：所有在线并玩游戏的玩家都呈现为玩家进程（gen_server）。每个玩家的所有数据和业务逻辑都在其玩家进程中。有时，每个参与者进程都会决定将其状态保存在 riak 中。
到目前为止似乎是非常快速有效的方法。
更新：现在我们使用 PostgreSQL。太棒了！
I agree with Hynek -Pichi- Vychodil. Riak is a great thing for key-valye storage.
We use Riak almost 95% for the same thing you described. Everything works so far without any issues. In case you will hit performance limitation of Riak - add more nodes and it good to go!
Another cool thing about Riak is its very low performance degradation over the time. You can find more information about benchmarking Riak here: http://joyeur.com/2010/10/31/riak-smartmachine-benchmark-the-technical-details/
In case you go with it:
About membase and memory usage: I also tried membase, but I found that it is not suitable for my tasks - (membase declares fault tolerance, but I could not setup it in the way it should work with faults, even with help from membase guys I didn't succeed). So at the moment I use the following architecture: All players that are online and play the game are presented as player-processes (gen_server). All data data and business logic for each player is in its player-process. From time to time each player-process desides to save its state in riak.
So far seems to be very fast and efficient approach.
Update: Now we are with PostgreSQL. It is awesome!
您可以查看 bitcask 或其他Riak 后端来存储您的数据。避免 IPC 绝对是个好主意，所以将其保留在 Erlang 中。
You can look to bitcask or other Riak backends to store your data. Avoid IPC is definitely good idea, so keep it inside Erlang.