接受数据库写入的速度比数据库实际写入的速度快
我们有一个解决方案,该解决方案分布在全球范围内的几台 Sybase DB 服务器上,并以 Oracle Coherence 缓存为前端。
现在,我们需要支持“缓存速度写入”,但由于数据库的国际复制性质,我们需要比数据库实际写入数据的速度更快地接受数据库持久化的数据,您可能都会同意这一点一个问题。
因此,我想知道解决这种情况的建议方法是什么。
注意点:
- 没有任何限制
- 根据使用情况统计划分多个分片
We have a solution which is spread globally across a few Sybase DB servers and fronted by an Oracle Coherence cache.
Now, we need to support 'cache speed writes', yet due to the internationally-replicated nature of our DB, we need to accept data for DB persisting faster than the DB can actually write the data, which you will probably all agree is quite a problem.
I am therefore wondering what the recommended approach to tackle this situation would be.
Points of note:
- There are no constraints
- There are multiple shards split according to usage statistics
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
需要考虑的一种方法是:
如果您正在写入读取优化的数据库或表,数据库的写入速度可能会比您需要的慢。可能涉及很多约束和索引,并且“浪费”大量时间来检查和重新计算它们。
您可能需要考虑使用适当的写入优化存储引擎且没有索引的单独模式或表集。这里可能会有显着的性能提升。
然后将有另一个进程将数据从写优化模式传输到读优化(永久)模式。
本质上,如果同步进程遇到限制,则可以通过引入限制和/或队列机制将其拆分为多个异步进程。
One approach to consider:
DB may potentially write slower than you need if you're writing to a read-optimized database or tables. There could be a lot of constraints and indexes involved, and a lot of time "wasted" having them checked and re-calculated.
You might want to consider a separate schema or set of tables with an appropriate write-optimized storage engine and no indexes. There could be substantial performance gains here.
There will be another process then that will transfer data from write-optimized to read-optimized (permanent) schema.
In essence, if a synchronous process running into limitations, one would split it in multiple asynchronous processes with introduction of throttling and/or queue mechanisms.
我决定对一些较大且访问频率较高的表使用水平分区,这是 Sybase ASE 15+ 本身支持的功能,并且对客户端应用程序是透明的。
I have decided to use horizontal partitioning on some of the larger and more frequently accessed tables, which is something that is natively supported by Sybase ASE 15+ and is transparent to client applications.