对称数据库中哪种更好的架构传输数据？ [英] Which better architecture in symmetric bettwen databases transfer data ?

问题描述

规格

大数据，10小时内最少10万次交易，第一级300个节点

对称范围内的每个表都有更新插入删除触发器

架构方法

1-one corp通过直接DB连接发送数据与其他调解器（节点）

（一项服务）

2-one corp通过tcp连接发送数据，另一个服务为每个获得同步交易的节点发送数据并通过tcp发送给公司服务

（两个服务）



我尝试了什么：



i认为架构方法1更强大2但我不确定

Specs
Big data with minimum 10 thousand transaction in 10 h and 300 nodes at first stage
every table in symmetric scope has update insert delete trigger
architecture methods
1-one corp send data via direct DB Connection with to other mediators (nodes)
(one service)
2-one corp send data via tcp connection and another service for each nodes that get sync transaction and send it o corp service via also tcp
(two Service)

What I have tried:

i think the architecture methods 1 is more powerful 2 but i did't sure

推荐答案

最好将一些批次作为事务发送并获得保存/完成的提交，然后继续。您需要防止任何故障，如网络超时或任何其他故障，如无效数据。确保数据的完整性非常重要。事务需要提交和一些回滚。



建立TCP连接有一些成本，因此最好将它用于多个命令。有多少取决于服务器可以做什么。



考虑加密，以防止数据受到攻击或滥用。如果你有大数据量，你可以使用一些压缩和现代协议。

It is better to send some batches as transactions and get a commit that they are saved/done and than proceed. You need to protect against any failures, like network timeout or any other, like invalid data. It is very important that the integrity of the data is ensured. Transactions need a commit and some rollbacks.

Establishing a TCP-connection has some costs, so it is better to use it for multiple commands. How many is depended on what the servers can do.

And think about encryption so the data is protected against an attack or misuse. If you have big data volume you may use some compression and modern protocols.

方法1是优越的，原因如下：



1）您可以使用线程来处理并发性，在Windows中，至少（您没有指定操作系统）是一种高度开发，值得信赖且高效的机制，用于处理同步或异步任务分配。另一方面，你的方法2必须使用进程间分配和通信 - 通过TCP不少 - 这更容易受到错误和问题的影响，而且速度更慢，资源更密集。



2）高流量异步数据库访问已经充满了已知问题 - 我在某处读到某人实际上写了一篇论文，证明100％完全透明的数据库是不可能实现的 - 所以将TCP添加到该混合中，其具有其自身的非常重要的假设场景，仅用于增加任何高流量数据库访问情况所固有的复杂性。



从理论上讲，方法1的唯一缺点就是*如果*你的操作变得如此之大以至于它需要多台机器来处理负载，你必须将所有的机器分开（也就是：端口）基于线程的节点代码到单独的DCOM模块中，并在不同的机器上实现。这将是昂贵的，耗时的，并且是一个巨大的头痛。



然而，这些天，这项技术（DCOM）相当陈旧。今天增长服务器软件（处理更大负载）的一种更现代，更有效，更有效的方法是使用GPGPU，这已经是一种基于线程的技术，因此将任何现有的基于线程的代码移植到GPGPU比使用DCOM更容易，更具成本效益。它也可以零碎地完成，不像DCOM，如果由专业人员处理，甚至可以在没有停机的情况下实施..



希望这有帮助..

Method 1 is superior for the following reasons:

1) You can use threads to handle concurrency which, in Windows at least (you didn't specify the OS), is a highly developed, trustworthy, and efficient mechanism for handling either synchronous or asynchronous task allocation. Your method 2, on the other hand, would have to use inter-process allocation and communication - over TCP no less - which is far more susceptible to bugs and problems, as well as being slower and more resource-intensive.

2) High-traffic asynchronous database access is already fraught with known issues - I read somewhere that someone actually wrote a paper proving that a 100% fully transparent database was impossible to achieve - so adding TCP to that mix, which has its own non-trivial set of 'what-if' scenarios, would only serve to compound the complexity inherent is any high-traffic database access situation.

Theoretically, the only downside to your method 1 is that *if* your operation ever got so big that it required multiple machines to handle the load, you'd have to separate out (aka: port) all of your thread-based 'node' code into separate DCOM modules, and implement those on separate machines. That would be expensive, time-consuming, and a huge headache.

HOWEVER, these days, that technology (DCOM) is pretty dated. A far more modern, effective, and efficient way to "grow" Server software today (to handle bigger loads) is by using GPGPU, which is already a thread-based technology, so porting any of your existing thread-based code to GPGPU would be far easier and more cost-effective than using DCOM. It could also be done piecemeal, unlike DCOM, and if handled by professionals, could even be implemented with NO downtime..

Hope this helps..

这篇关于对称数据库中哪种更好的架构传输数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！