Интеллектуальный поиск и анализ информации

4. Слабые ACID свойства.

Долгое время консистентность (consistency) данных была “священной коровой” для архитекторов и разработчиков. Все реляционные базы обеспечивали тот или иной уровень изоляции — либо за счет блокировок при изменении и блокирующего чтения, либо за счет undo-логов. С приходом огромных массивов информации и распределенных систем стало ясно, что обеспечить для них транзакционность набора операций с одной стороны и получить высокую доступность и быстрое время отклика с другой — невозможно. Более того, даже обновление одной записи не гарантирует, что любой другой пользователь моментально увидит изменения в системе, ведь изменение может произойти, например, в мастер-ноде, а реплика асинхронно скопируется на слейв-ноду, с которой и работает другой пользователь. В таком случае он увидит результат через какой-то промежуток времени. Это называется eventual consistency и это то, на что идут сейчас все крупнейшие интернет-компании мира, включая Facebook и Amazon. Последние с гордостью заявляют, что максимальный интервал, в течение которого пользователь может видеть неконсистентные данные составляют не более секунды. Пример такой ситуации показан на рисунке:
ГРАФОВЫЕ БАЗА ДАННЫХ

SQL *NoSQL *
На Хабре не утихают споры о том, какие базы данных лучше и круче, дискуссии о перспективах SQL и NoSQL. Я не удержался и решил порассуждать о том, где могут быть полезны именно графовые БД.


Прежде чем начать, давайте задумаемся, какая информация имеется у нас сегодня на повестке дня? Это уже не просто данные – это весьма непредсказуемая структура, которая со временем может превратиться либо в BigData, либо в сложную семантическую сеть, и часто разработчик не может заранее сказать, какой она будет. Так как же выбрать базу данных – или хотя бы ее архитектуру, чтобы создать действительно быстрое и эффективно работающее приложение?

Чтобы ответить на этот вопрос, попробуем немножко систематизировать ту информацию о базах данных, которая есть у нас. Первый и самый известный кандидат на эксплуатацию – это реляционные базы данных с их единым языком SQL. Просто, удобно и стандартно. Именно благодаря стандартизации реляционные базы данных заработали себе популярность и доминируют на рынке. Но по факту реляционные базы данных – это же просто таблицы, где в каждой строке выстраивается однозначное соответствие между ключом и его многочисленными (или малочисленными) параметрами. Пока приложения обходились отдельными таблицами и не рассматривали особенных взаимодействий между собой и разными типами данных, этого было вполне достаточно.