С какими проблемами масштабируемости вы столкнулись с использованием хранилища данных NoSQL?

Ответ 1

Я переключил небольшой подпроект из MySQL в CouchDB, чтобы иметь возможность обрабатывать нагрузку. Результат был потрясающим.

Около 2 лет назад мы выпустили собственное программное обеспечение на http://www.ubuntuusers.de/ (который, вероятно, является крупнейшим немецким сайтом сообщества Linux), Сайт написан на Python, и мы добавили промежуточное программное обеспечение WSGI, которое смогло поймать все исключения и отправить их на другой небольшой веб-сайт с MySQL. Этот небольшой веб-сайт использовал хэш для определения различных ошибок, а также сохранил количество вхождений и последнее вхождение.

К сожалению, вскоре после релиза веб-сайт traceback-logger больше не отвечал. У нас были некоторые проблемы с блокировкой с производством db нашего основного сайта, который бросал исключения почти на каждый запрос, а также несколько других ошибок, которые мы не изучали на этапе тестирования. Серверный кластер нашего основного сайта, называемый трассировочной записью, отправляет страницу несколько раз в секунду. И это было слишком много для небольшого сервера, на котором размещался журнал трассировки (он уже был старым сервером, который использовался только для целей разработки).

В это время CouchDB был довольно популярен, и поэтому я решил попробовать его и написать с ним небольшой трассировочный журнал. Новый регистратор состоял только из одного файла python, который предоставил список ошибок с параметрами сортировки и фильтрации и страницей отправки. И на заднем плане я начал процесс CouchDB. Новое программное обеспечение быстро отреагировало на все запросы, и нам удалось просмотреть огромное количество отчетов об ошибках.

Интересно, что решение раньше выполнялось на старом выделенном сервере, где новый сайт на основе CouchDB, с другой стороны, работал только на общем экземпляре xen с очень ограниченными ресурсами. И я даже не использовал силу хранилищ ключей для масштабирования по горизонтали. Способность CouchDB/Erlang OTP обрабатывать параллельные запросы без блокировки была уже достаточной для удовлетворения потребностей.

Теперь быстро записываемый журнал CouchDB-traceback продолжает работать и является полезным способом изучения ошибок на главном веб-сайте. Во всяком случае, примерно раз в месяц база данных становится слишком большой, и процесс CouchDB убивается. Но тогда команда compact-db CouchDB снова уменьшает размер от нескольких ГБ до некоторых КБ, а база данных снова запускается и запускается (возможно, мне стоит рассмотреть возможность добавления там cronjob... 0o).

В сводке CouchDB был, безусловно, лучшим выбором (или, по крайней мере, лучшим выбором, чем MySQL) для этого подпроекта, и он хорошо выполняет свою работу.

Ответ 2

Мой текущий проект на самом деле.

Сохранение 18 000 объектов в нормализованной структуре: 90 000 строк по 8 различным таблицам. Получил 1 минуту, чтобы получить и сопоставить их с нашей объектной моделью Java, которая со всем правильно проиндексирована и т.д.

Сохранение их в виде пар ключ/значение с использованием легкого текстового представления: 1 таблица, 18 000 строк, 3 секунды для их восстановления и восстановления объектов Java.

В бизнес-условиях: первый вариант невозможен. Второй вариант означает, что наше приложение работает.

Сведения о технологии: работа с MySQL для SQL и NoSQL! Придерживание MySQL для хорошей поддержки транзакций, производительности и проверенной репутации для невращающихся данных, масштабирования достаточно хорошо, поддержки кластеризации и т.д.

Наша модель данных в MySQL теперь представляет собой только ключевые поля (целые числа) и большое поле "значение": просто большое поле TEXT.

Мы не ходили с кем-либо из новых игроков (CouchDB, Cassandra, MongoDB и т.д.), потому что, хотя они каждый из них предлагают отличные функции/производительность сами по себе, всегда были недостатки для наших обстоятельств (например, отсутствие/незрелая поддержка Java).

Дополнительное преимущество (ab) с использованием MySQL - биты нашей модели, которые работают реляционно, могут быть легко связаны с данными о хранении ключа/значения.

Обновление: здесь пример того, как мы представляли текстовое содержимое, а не наш фактический бизнес-домен (мы не работаем с "продуктами" ), поскольку мой босс меня снимает, но передает эту идею, включая рекурсивный аспект (один сущность, здесь продукт, содержащий "другие" ). Надеюсь, это ясно, как в нормализованной структуре это может быть довольно много таблиц, например. присоединение продукта к его ассортименту вкусов, которые содержатся в других продуктах и ​​т.д.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Ответ 3

Тодд Хофф highscalability.com имеет большой обзор NoSQL, включая некоторые тематические исследования.

Коммерческая Vertica столбчатая СУБД может соответствовать вашим целям (даже если она поддерживает SQL): она очень быстро по сравнению с традиционными реляционными СУБД для аналитические запросы. См. Stonebraker, et al. недавний документ CACM, контрастирующий Vertica с уменьшением карты.

Обновление: Twitter выбрал Cassandra для нескольких других, включая HBase, Волдеморт, MongoDB, MemcacheDB, Redis и HyperTable.

Обновление 2: Рик Кэттелл только что опубликовал сравнение нескольких систем NoSQL в Высокопроизводительных хранилищах данных. И highscalability.com взять на бумаге Рика здесь.

Ответ 4

Мы переместили часть наших данных из mysql в mongodb, не столько для масштабируемости, сколько из-за того, что они лучше подходят для файлов и не табличных данных.

В настоящее время мы производим:

• 25 тыс. файлов (60 ГБ)
• 130 миллионов других "документов" (350 ГБ)

с ежедневным оборотом около 10 ГБ.

База данных развернута в "спаренной" конфигурации на двух узлах (6x450GB sas raid10) с клиентами apache/wsgi/python, используя mongodb python api (pymongo). Установка диска, вероятно, слишком сложна, но это то, что мы используем для mysql.

Помимо некоторых проблем с pymongo threadpools и блокирующего характера сервера mongodb, это был хороший опыт.

Ответ 5

Я прошу прощения за то, что вы не согласны с вашим жирным шрифтом, так как у меня нет опыта из первых рук, но этот набор сообщений в блогах - хороший пример решения проблемы с CouchDB.

CouchDB: Пример из практики

По сути, приложение textme использовало CouchDB для решения проблемы их взрыва. Они обнаружили, что SQL слишком медленный, чтобы иметь дело с большим количеством архивных данных, и переместил его в CouchDB. Это превосходное чтение, и он обсуждает весь процесс выяснения, какие проблемы CouchDB может решить и как они решили их решить.

Ответ 6

Мы переместили некоторые из наших данных, которые мы использовали для хранения в Postgresql и Memcached, в Redis. Хранилища ключевых значений намного лучше подходят для хранения данных иерархических объектов. Вы можете хранить данные blob намного быстрее и с гораздо меньшим временем разработки и усилиями, чем использовать ORM для сопоставления вашего блоба с RDBMS.

У меня есть клиент с открытым исходным кодом С# redis, который позволяет хранить и извлекать любые объекты POCO с 1 строкой:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

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

Я рассматриваю Redis как "управляемый текстовый файл" на стероидах, который обеспечивает быстрый, параллельный и атомный доступ для нескольких клиентов, поэтому все, что я использовал для использования текстового файла или встроенной базы данных, теперь использую Redis. например Чтобы получить комбинированный журнал ошибок в режиме реального времени для всех наших сервисов (который, как известно, был для нас трудной задачей), теперь выполняется только с несколькими строками, только предварительно ожидая ошибку в списке сторон сервера Redis, а затем обрезка списка, так что сохраняются только последние 1000, например:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

Ответ 7

У меня нет опыта из первых рук., но я нашел этот блог довольно интересным.

Ответ 8

Я нахожу усилия для сопоставления объектов домена программного обеспечения (например, aSalesOrder, aCustomer...) с двумерной реляционной базой данных (строками и столбцами), занимает много кода для сохранения/обновления, а затем снова для создания экземпляра объекта домена из нескольких таблиц. Не говоря уже о производительности, связанной с тем, что все эти соединения объединяются, все эти диски читаются... просто для просмотра/управления объектом домена, такого как заказ клиента или запись клиента.

Мы переключились на системы управления базами данных объектов (ODBMS). Они превосходят возможности перечисленных систем noSQL. Подобным примером является GemStone/S (для Smalltalk). Существуют и другие решения ODBMS, в которых есть драйверы для многих языков. Ключевое преимущество разработчика, ваша иерархия классов - это автоматически ваша схема базы данных, подклассы и все. Просто используйте свой объектно-ориентированный язык, чтобы объекты сохранялись в базе данных. Системы ODBMS обеспечивают целостность транзакции уровня ACID, поэтому она также будет работать в финансовых системах.

Ответ 9

Я этого не делаю. Я хотел бы использовать простой и бесплатный хранилище ключей, который я могу вызвать в процессе, но такая вещь не существует afaik на платформе Windows. Теперь я использую Sqlite, но я хотел бы использовать что-то вроде Tokyo Cabinet. BerkeleyDB имеет лицензионные "проблемы".

Однако, если вы хотите использовать ОС Windows, ваш выбор баз данных NoSQL ограничен. И не всегда есть поставщик С#

Я попробовал MongoDB, и это было в 40 раз быстрее, чем Sqlite, поэтому, возможно, я должен его использовать. Но я все еще надеюсь на простое решение в процессе.

Ответ 10

Я использовал redis для хранения сообщений журнала на машинах. Это было очень легко реализовать и очень полезно. Редис действительно качает

Ответ 11

Мы заменили базу данных postgres базой данных CouchDB, потому что отсутствие фиксированной схемы было для нас сильным преимуществом. Каждый документ имеет переменное количество индексов, используемых для доступа к этому документу.

Ответ 12

Я переключился с MySQL (InnoDB) на cassandra для системы M2M, которая в основном хранит временные ряды датчиков для каждого устройства. Каждая информация индексируется (device_id, date) и (device_id, type_of_sensor, date). Версия MySQL содержала 20 миллионов строк.

MySQL:

• Настройка синхронизации master-master. Немного возникла проблема с потерей синхронизации. Это было напряженным, и особенно в начале могли занять несколько часов, чтобы исправить.
• Время ввода не было проблемой, но запрос требовал все больше и больше памяти по мере роста данных. Проблема заключается в том, что индексы рассматриваются как единое целое. В моем случае я использовал только очень тонкие части индексов, которые были необходимы для загрузки в память (только несколько процентов устройств часто отслеживались и находились на самых последних данных).
• Было сложно создать резервную копию. Rsync не может делать быстрые резервные копии в больших файлах таблицы InnoDB.
• Быстро стало ясно, что не удалось обновить схему тяжелых таблиц, потому что это заняло слишком много времени (часы).
• Импорт данных занял часы (даже если индексирование было завершено в конце). Лучший план спасения состоял в том, чтобы всегда хранить несколько копий базы данных (файл данных + журналы).
• Перенос из одной хостинговой компании в другую был действительно большой проблемой. Репликация должна была быть обработана очень осторожно.

Cassandra:

• Еще проще установить, чем MySQL.
• Требуется много оперативной памяти. Экземпляр 2 ГБ не мог заставить его работать в первых версиях, теперь он может работать на экземпляре 1 ГБ, но это не идея (слишком много данных сбрасывается). Давать 8GB было достаточно в нашем случае.
• Как только вы поймете, как вы упорядочиваете свои данные, хранение легко. Запрос немного сложнее. Но как только вы обойдетесь, это очень быстро (вы не можете ошибиться, если не хотите).
• Если предыдущий шаг был выполнен правильно, он находится и остается супер-быстрым.
• Кажется, что данные упорядочены для резервного копирования. Все новые данные добавляются в виде новых файлов. Я лично, но это нехорошо, очищайте данные каждую ночь и перед каждым отключением (обычно для обновления), так что восстановление занимает меньше времени, потому что у нас меньше журналов для чтения. Он не создает много файлов, они уплотняются.
• Импорт данных быстро, как черт. И чем больше хостов у вас, тем быстрее. Экспорт и импорт гигабайт данных больше не проблема.
• Отсутствие схемы - очень интересная вещь, потому что вы можете сделать ваши данные развитыми, чтобы соответствовать вашим потребностям. Это может означать одновременное использование разных версий ваших данных в одном семействе столбцов.
• Добавление хоста было легким (хотя и не быстрым), но я не делал этого в настройке нескольких датацентров.

Примечание. Я также использовал elasticsearch (ориентированный на документ на основе lucene), и я думаю, что это следует рассматривать как базу данных NoSQL. Он распределен, надежен и часто быстр (некоторые сложные запросы могут выполняться довольно плохо).

Ответ 13

Я использовал Couchbase в прошлом, и мы столкнулись с проблемами перебалансировки и множеством других проблем. В настоящее время я использую Redis в нескольких производственных проектах. Я использую redislabs.com, который является управляемой службой Redis, которая заботится о масштабировании кластеров Redis. Я опубликовал видео на тему сохранения объектов в своем блоге в http://thomasjaeger.wordpress.com, в котором показано, как использовать Redis в модели поставщика и как хранить ваши Объекты С# в Redis. Посмотрите.

Ответ 14

Я бы посоветовал всем, кто читает это, снова попробовать Couchbase теперь, когда 3.0 выходит за дверь. Для начинающих доступно более 200 новых функций. Производительность, доступность, масштабируемость и удобные функции управления Couchbase Server обеспечивают чрезвычайно гибкую и доступную базу данных. Интерфейс управления является встроенным, и API автоматически обнаруживают узлы кластера, поэтому нет необходимости в балансировщике нагрузки из приложения в БД. Хотя в настоящее время у нас нет управляемой службы, вы можете запускать couchbase на таких вещах, как AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers, такие как CloudSoft и многое другое. Что касается ребалансировки, это зависит от того, что конкретно вы имеете в виду, но Couchbase автоматически не восстанавливает баланс после сбоя node, как это было предусмотрено, но администратор может настроить автоматический переход на другой ресурс при первой ошибке node и используя наши API-интерфейсы, вы также можете получить доступ к репликам vbuckets для чтения, прежде чем сделать их активными или использовать RestAPI, вы можете принудительно выполнить переход на другой ресурс с помощью средства мониторинга. Это особый случай, но это можно сделать.

Мы склонны не перебалансироваться практически в любом режиме, если только node не находится в автономном режиме и никогда не возвращается или новый node готов к сбалансированности автоматически. Вот несколько руководств, которые помогут всем, кто интересуется, какая из наиболее высокопроизводительных баз данных NoSQL - это все.

• Couchbase Server 3.0
• Руководство администратора
• REST API
• Руководства разработчика

Наконец, я также рекомендую вам проверить N1QL для распределенного запроса:

• Учебное пособие по N1QL
• Руководство по N1QL

Спасибо за чтение и дайте мне или другим знать, нужна ли вам дополнительная помощь!

Остин