【问题标题】:How to handle db concurrency?如何处理数据库并发?
【发布时间】:2018-10-03 15:52:11
【问题描述】:

假设我有 3 张桌子(LiveDataTableReducedDataTableScheduleTable)。

基本上我有一个事件流 -> 每当我收到一个事件时,我都会将该事件的提取数据写入LiveDataTable

问题是有大量的事件,这就是为什么LiveDataTable 可能变得非常庞大,所以我有另一个ReducedDataTable 合并来自LiveDataTable 的行(想想从LiveDataTable 中选择100 行,将其减少为 1 行并将其写入 ReducedDataTable,然后从 LiveDataTable 中删除这 100 行。

为了确定执行这些reducing operations 的正确时间,有ScheduleTable。你可能会认为 1 行 ScheduleTable 对应于 1 reducing operation

我希望能够支持来自InterfaceList<Data> getData() 方法。有两种情况:我应该只从ReducedDataTable 读取或合并ReducedDataTableLiveDataTable 的结果。

以下是我的缓存如何分步工作:

  1. ScheduleTable读取1行
  2. 读自LiveDataTable
  3. 写信给ReducedDataTable(至少4行)
  4. LiveDataTable 中删除 (
  5. ScheduleTable 中删除 1 行

问题是我想确定在接收getData() 请求时是否应该以编程方式读取LiveDataTableReducedDataTable。对于每一步(在#3 之前),我想从LiveDataTable 阅读,然后我想从ReducedDataTable 阅读。收到getData() 请求时,如何确定我当前所处的步骤?

我问这个问题的原因我相信这是处理并发时数据库中的一个常见问题。

【问题讨论】:

  • 这听起来相当复杂。如果您的写入是不可变的并且您正确构建了数据模型,那么您应该能够写入一个表,然后条目会更新旧表。也许你不能这样做是有原因的?
  • 我使用 Cassandra,所以它不遵循 ACID。
  • 对不起,我应该更清楚一点。即使使用 Cassandra,这似乎也令人费解。 Cassandra 推荐的方法之一是拥有一个不可变的数据模型,因为您无法保证给定的写入何时可能进入集群,因为这是由许多因素决定的。当然,您可以使用 LWT 之类的东西,但这样做很昂贵,并且由于使用 paxos 方法会损失一些性能。例如,您将一个表中的行组合到另一个表中,每次都有效地执行 ETL。你不能用时间戳或类似的东西来键入你的分区吗?

标签: database concurrency cassandra


【解决方案1】:

(假设你的压缩过程足够快) 您可以先乐观地从小表中读取数据,如果数据丢失 - 然后从非压缩表中读取。 在大多数情况下,只有一个请求,而不是两个。

否则你可以维护已经被压缩的数据的时间戳。

【讨论】:

    猜你喜欢
    • 2011-05-24
    • 1970-01-01
    • 1970-01-01
    • 2013-08-18
    • 1970-01-01
    • 2018-12-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多