3

在决定我自己的产品的技术堆栈时，我决定使用 scyllaDB 作为数据库，因为它具有令人印象深刻的性能。

对于本地开发，我在我的 Macbook 上设置了 Cassandra。考虑到 ScyllaDB 现在支持（实验）MV（Materialized View），它使开发变得容易。对于开发服务器，我在 Linod 上托管的 Ubuntu 16.04 上运行 ScyllaDB。

我面临以下问题：

  1. 几周后，有一天，当我使用分区键从基表（从在 Ubuntu 上运行的 ScyllaDB）中删除一个条目时，相应的 MV 仍然显示已删除记录的相应条目。在我删除整个 Key-Space 并重新创建它后，它已修复，但我无法确定导致这种不一致的原因。

  2. 当我删除 MV 并重新创建它时，它并没有复制旧数据。我试图搜索，但找不到强制 MV 从基表读取并填充自身的方法。

对于第一个问题，我想知道是否有人遇到过类似的情况。另外，如果我可以采取任何措施来防止这种情况发生，或者如果无法防止这种情况发生，那就是“实验性”的意思。

任何帮助或参考表示赞赏。

4

4 回答 4

3

在 2.1 中，Scylla 缺少视图构建（即使用现有数据来填充创建时的视图），但这在 2.2 中得到了解决。

于 2018-07-01T22:54:55.023 回答
2

事实上，2.1 的 MV 状态是不完整的。它在本周发布的 2.2 中变得更好。它还不是 GA，但我们在 2.2 之上有一个分支，它合并了几乎存在的 master 的新更改。它应该在 2 个月内达到 GA 质量。

请注意，Cassandra MV 状态是实验性的，我们一直在打开 JIRA 票证，我们发现 C* 的 MV 存在设计缺陷。

于 2018-06-30T08:42:06.897 回答
1

tldr; I would suggest you either stick with cassandra if you want MV, or manually do the MV's in scylla.

Materialized views are super experimental. I ran them for about 6 months in production replacing their functionality manually. This was done to improve performance. So if performance is your goal here, I suggest avoiding them.

I can attest that the materialized views if created on a already populated table will infact populate the materialized view on their own so this seems like a scylladb problem. Cassandra has a different problem where the writes will crater the DB if you do this on a large production table.

I also did not have issues with truncating the primary table and seeing the reflection in cassandra.

Additionally I had tried scylladb for a spike for performance reasons. I found it very difficult to work with and dropped it after spending a week trying to get it to do what I knew cassandra would do.

于 2018-06-29T14:05:46.173 回答
0

Thanks @Highstead for confirming the automatic population of MV if base table has entries while creating the MV.

For the main query of the inconsistency in tables and MV, I found out that it was due to truncate query on base table.

Also found an issue for it https://github.com/scylladb/scylla/issues/3188

It states that currently, truncating the base table wont clear the MVs created from that table.

Vice-versa, you can run truncate query on the MV and it won't throw an exception (where it should've) and MV will be cleared even when base table contains entries.

So solution for now is to truncate each MV along with tables separately.

于 2018-06-30T11:55:58.283 回答