管理国际股票交易数据库面临哪些挑战？

Question

我是一名学生，我有一个问题要做：

数据库管理员在设计实时、24小时、一周6天的国际股票交易系统时面临哪些问题和挑战？基于云的数据库系统是一种可行的服务吗？

Answer 1

因为它是一个系统，所以您将有许多相互作用的子系统，包括电源、环境控制、通信、硬件，然后再加上数据管理和其他一切。

有些方面跨越了所有这些层，如安全性、冗余性、业务连续性等。

仅仅从数据库方面来说，您就需要考虑事务负载、平衡负载的体系结构、存储需求、响应时间需求。

一切都取决于需求--其中有许多来自监管机构、客户、用户、业务合作伙伴。

至于基于云的数据库是否可行，如果您的组织必须对系统负责的话，我不认为其中任何一个都是可行的。

任何时候，当你外包任何东西时，都会限制你对需求作出反应的能力。有些事情比其他事情更容易减轻。例如，您决定在系统中使用一个软件库作为组件--如果您有源代码，可以随时修改这个库，或者自己重写它，或者将它替换掉。或者选择像Oracle或SQL Server这样的RDBMS，在那里您可以让供应商做一个概念的证明，并得到高度的支持，因为销售量很大。

这并不是说，通过放松你的要求，你不能使用谷歌应用程序BigTable、亚马逊或Azure什么的，但简单的事实是，即使有了合同，你对另一个组织的系统也有有限的控制权，而且你正在依赖它们。

所有的系统都是通过权衡权衡来建立的。

Answer 2

为灾难场景或安全漏洞进行规划、测试和执行将是一个巨大的挑战。您还必须记住，您还必须在环境中实现某种形式的管理项目。

Answer 3

没有。24/6是相当好的-你是一个系统的维护是一个真正的问题。

主要的问题可能是--而且请不要编辑出钝的语言--如果一些morong愚蠢的架构师没有为24/6设计这个系统。也就是说，如果它不适用于复制，或者需要强制维护(在空闲的日子)，这样管理员就没有机会在那里做系统级的事情了。

如果它是为正常运行时间使用sql服务器的所有功能而设计的，那么24/6是一个非常好的、易于使用SLA的工具。

你也可能每天都有一个小的维修窗口--你没有这么说，但我知道即使外汇每天也睡一个小时，仅仅是因为在这段时间里没有主要的地点有繁忙的时间。而外汇是不受监管的。因此，你可以每天做一些小事情。

尽管如此，一个好的设计可能会将数据库按位置(或组码，这样您可以将所有欧洲人都放在一台服务器上，所有美国人都放在一台服务器上)进行分区，并允许分片--如果美国市场关闭，美国负责的服务器将不会更新。因为“大陆”主要是共享时区(是的，我知道美国覆盖的更多--但不是太过)，这给了你每个大陆的维修窗口。

基于云的可能根本不起作用，因为基于云的只是很小的东西。尝试找到一个为中型数据库提供云存储的人，你会大吃一惊。提示:中等大小可能是100gb+。这也取决于“股票交易”的作用。你测试策略吗？大规模的？我目前只做期货交易-22个符号-和我们的模拟生成大约50 do 75 do的数据每天进行分析后，压缩。200岁以前。我利用分阶段分区(sql server)，只是为了能够在常规维护期间快速删除坏结果--否则，我会执行数亿行delete语句。我为客户建立的上一个风险管理数据库(能源，而不是库存--如此少的符号)的空间分配为20 an，使用的是甲骨文ExaData硬件集群(3拷贝)，在3个位置复制)。这真的取决于客户的规模有多大。

话虽如此，这里有一个真正值得思考的问题:什么是“股票交易”？如果它是“手动”或“自动慢”，那么这并不是太苛刻--甚至1000名交易员也不会从db的角度做大量交易。

如果是HFT -高频率嫉妒交易-你可能有一个单一的一只股票，有时做100次/秒。添加许多市场，许多符号，许多标志，你不能在sql中扩展它--这就是为什么那些algos写日志，将东西保存在内存中，然后定期从日志中导入事务。在SQL中，实时对于高频交易来说是不可行的--尤其是因为它会影响机器(降低交易速度)。当你数到百万分之一秒(是的，它们现在工作在微秒级)，并使用编程硬件(FPGA)使价格源解析比下一台机器更快--你真的可以把事情解耦。当SQL决定提交有关购买的事务时，价格可能已经走得太远了;)而且不要说多线程。我知道一些基础设施。在燃烧模式下，每个内核运行一个线程，硬连接到核心--并无休止地循环检查另一个核心放置数据的位置。你很容易从试图在美国股市之间进行套利的人那里获得每秒20.000笔交易的高峰负荷。这是每笔交易--而且也有一些。

正如我所说-这是一个非常复杂的系统设置。很大程度上取决于建筑。