订单簿数据库设计
OrderBook 充满了买卖订单。更新，新订单可能会执行交易。
我似乎找不到任何实施的例子。
我们可以给每个订单一个id，然后逐一检查执行订单。但我们想要能够扩展到数千个活跃订单的东西。
我们可以对价格进行排序以获得将要执行的订单（因为它们重叠）。但我们必须小心，只能按照收到订单的顺序执行:)
有什么想法吗？
The OrderBook is filled with buy and sell orders. Updates, new orders may execute trades.
I can't seem to find any examples of implementation.
We could give each order an id, and checkExecute orders one by one. But we want something that will scale to thousands of active orders.
We can sort the prices to get the orders that will be executed (because they overlap). But we have to be careful and execute only in the order in which the orders were received :)
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Python 的 OrderedDict 可以作为可扩展 OrderBook 的基础。您需要为每个价格级别准备一个有序字典，以便订单根据价格/时间优先级进行匹配。
Python's OrderedDict can serve as a foundation for a scalable OrderBook. You would want one ordered dictionary for each price-level so that orders will match according to price/time priority.
市场数据通常以时间序列方式建模，因此它自然是按时间戳排序的，时间戳最多可达目前精度为皮秒。
根据您所依赖的技术，如果您不介意付费，我会选择 OneTick，这是一个时间序列数据库，已经有一个内置的订单簿，其中包含订单深度/价格水平、CEP 等。
如果您想自己构建它（或依赖免费产品），请查看OpenTSDB，它是具有 LGPLv3+ 许可证的开源时间序列数据库。当然，它会比 OneTick 慢，但由于您只需要数千个（OneTick 处理数十亿个），具体取决于您的速度要求，它可能会起作用。
至于 OrderBook 数据模型，这取决于您将如何准确地使用这本书：例如，您是否关心多个价格水平？书的顶部？您是否需要将出价/要价与实际订单相匹配等。
但是您可以从设计一个记录 OrderBook 事件的模式开始，例如：
示例来自 LMAX协议参考指南
Market data is usually modeled in a time series fashion, hence it is naturally ordered by a timestamp which goes up to as far as a picosecond precision at the moment.
Depending on what tech you rely on, if you don't mind to pay for it, I would go with OneTick, that is a time series DB that already has a built in order book with a book depth / price levels, CEP and much more.
In case you'd like to build it yourself ( or rely on free products ), take a look at OpenTSDB which is an open source, time series DB with a LGPLv3+ license. It'd be slower than OneTick of course, but since you just need thousands (OneTick handles billions) depending on your speed requirements it may work.
As to the OrderBook data model it would depend on how exactly are you going to use the book: e.g. do you care about multiple price levels? Top of the book? Do you need to match bids/asks to the actual orders, etc..
But you can start with designing a schema that would record OrderBook events such as:
The example is from LMAX Protocol Reference Guide