2016-03-26 5 views
0

Я пишу код для CMS, используя Cassandra в качестве системы баз данных.Можно ли избежать проблем надгробий с Кассандрой?

Одна из сильных сторон CMS состоит в том, чтобы предварительно вычислить всевозможные вещи, используя серверный компьютер, который постоянно работает с данными, которые изменяются в CMS.

Например, CMS сообщает системе списка, что страница была создана или изменена. Система списка сохраняет эту информацию в таблице с именем list. Эта информация - всего лишь один лайнер, который говорит мне, на какой странице нужно работать.

Column family: list 
    Row: concerned website (i.e. http://www.example.com/) 
    Column: full URI (i.e. http://www.example.com/this/page) 
     Value: true (because you need something for the column to exist) 

Однажды в некоторое время (чаще всего меньше, чем второй после простой страницы редактирования), что система списка бэкенда просыпается и видит, что определенная страница изменилась, и начинает работать на него, обновив все списки, которые включают (или больше не включать) эту страницу как элемент. Это позволяет переднему концу мгновенно знать количество элементов в списке и читать списки очень быстро, не выполняя сложные запросы в то время, когда список нужен (в отличие от того, что многие CMS делают с использованием SQL ...)

Фактически, я использую таблицу list как список TODO. Множество страниц, над которыми я должен работать. Таким образом, передняя часть добавляет ссылки на страницы в этот список, а бэкэнд удаляет их после их выполнения. В результате я могу получить очень большое количество надгробных камней в таблице list. Эффект реального мира: у меня были сбои в надгробных камнях, и система начала сбой в случайных местах. И однажды, когда список перестает работать, многие другие вещи в системе перестают работать, и сайты становятся непригодными для использования.

Я уменьшил время, необходимое Кассандре, чтобы заботиться о надгробных плитах в этом конкретном столе (и нескольких других), но мне интересно, использую ли я Кассандру, как ожидалось. Существует ли лучший способ обработки списка TODO такого рода в этой среде?

В качестве побочного примечания: список TODO может обрабатываться с различных компьютерных компьютеров. В небольшой системе у вас, вероятно, будет только один бэкэнд, работающий против данных списка, в более крупных системах с тысячами пользователей вы вряд ли будете иметь 2 или 3 бэкэнда только для обработки списков. Поэтому наличие данных в Кассандре очень практично, чтобы быстро разделить их между компьютерами.

+1

При написании нового приложения, вероятно, следует избегать бережливости, его устарело. –

+0

@ChrisLohfink, я начал с Cassandra 0.8, но мы работаем над получением CQL с Cassandra 3.x вместо бережливости. При этом мне все же хотелось бы знать, работает ли сортировка по-другому или нет ... –

ответ

3

Вы в основном реализована очередь, которая считается анти-модель для Кассандры: http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

Есть работа обходные и вещи, которые люди делают, чтобы сделать их лучше, но сложная игра, чтобы играть. Обязательно используйте LeveledCompactionStrategy, а не по умолчанию, это значительно поможет в меньших нагрузках. Рассмотрите работу вокруг, как временное боксирование разделов (строки в старой терминологической терминологии) и что в статье, приведенной выше, но вы можете искать другое решение.

+0

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

+0

Понижение ваших gc_grace_seconds тоже может быть хорошей идеей, но установка нуля - это плохо, так как вы можете потерять удаление. –

+0

Да, я положил его на 3600 за несколько столов ... на данный момент это, похоже, не вызывает проблем, но мы должны будем увидеть, как это происходит с 3.x, когда мы это сделаем. –

Смежные вопросы