ScyllaDB 2.1 - Несоответствие с материализованным представлением

Question

Принимая решение о стеке технологий для своего собственного продукта, я решил использовать scyllaDB для базы данных из-за его впечатляющей производительности.

Для локальной разработки я установил Cassandra на своем Macbook. Учитывая, что ScyllaDB теперь поддерживает (экспериментальный) MV (Materialized View), это облегчило разработку. Для сервера dev я использую ScyllaDB в Ubuntu 16.04, размещенном на Linod.

У меня возникли следующие проблемы:

1. Через несколько недель, однажды, когда я удалил запись из базовой таблицы (из ScyllaDB, работающей в Ubuntu) с помощью ключа разделения, соответствующий MV все еще показывал соответствующую запись для удаленной записи. Это было исправлено после того, как я отбросил все пространство ключей и пересоздал его, но я не могу точно определить, что вызвало это несоответствие.

2. Когда я уронил MV и пересоздал его, он не скопировал старые данные. Я попытался выполнить поиск, но не смог найти способ заставить MV читать из базовой таблицы и заполнить себя.

По первому вопросу я хотел бы знать, сталкивался ли кто-либо с подобным сценарием. Также, если есть что-то, что я могу сделать, чтобы предотвратить это, или если это не может быть предотвращено, и это значит быть «экспериментальным».

Любая помощь или ссылка приветствуется.

Answer 1

В 2.1 в Scylla отсутствовало построение представления (то есть использование существующих данных для заполнения представления о создании), но это решается в 2.2.

Answer 2

Действительно, статус MV 2.1 является неполным. В версии 2.2, которая выйдет на этой неделе, стало намного лучше. Это все еще не GA, но у нас есть ветка поверх 2.2, которая объединила более новые изменения с master, который почти там. Он должен достичь качества ГА в течение 2 месяцев.

Обратите внимание, что статус Cassandra MV является экспериментальным, и мы открываем билеты JIRA везде, где мы определили, что есть недостатки дизайна в C * MV.

Answer 3

Спасибо @Highstead за подтверждение автоматического заполнения MV, если в базовой таблице есть записи при создании MV.

Для основного запроса несоответствия в таблицах и MV я обнаружил, что это было связано с усеченным запросом к базовой таблице.

Также нашел проблему для этого https://github.com/scylladb/scylla/issues/3188

В нем говорится, что в настоящее время усечение базовой таблицы не приведет к очистке MV, созданных из этой таблицы.

И наоборот, вы можете запустить усеченный запрос на MV, и он не выдаст исключение (там, где он должен был), и MV будет очищен, даже если базовая таблица содержит записи.

Таким образом, решение сейчас состоит в том, чтобы урезать каждое MV вместе с таблицами отдельно.

Answer 4

tldr; Я бы посоветовал вам либо придерживаться кассандры, если вы хотите MV, либо вручную делать MV в scylla.

Материализованные представления являются супер экспериментальными. Я запускал их около 6 месяцев, заменяя их функциональность вручную. Это было сделано для улучшения производительности. Так что если ваша цель - производительность, я советую избегать их.

Я могу засвидетельствовать, что материализованные представления, если они созданы на уже заполненной таблице, будут влиять на заполнение материализованного представления самостоятельно, так что это похоже на проблему scylladb. У Кассандры есть другая проблема, когда записи будут записывать в БД, если вы сделаете это на большом рабочем столе.

У меня также не было проблем с усечением основной таблицы и просмотром отражения в Кассандре.

Кроме того, я пробовал scylladb для повышения производительности. Мне было очень трудно работать, и я бросил его, потратив неделю, пытаясь заставить его делать то, что, как я знал, будет делать Кассандра.