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

NoSQL относится к нереляционным хранилищам данных, которые порождают историю реляционных баз данных и гарантии ACID. Популярные хранилища данных NoSQL с открытым исходным кодом включают в себя:

• Кассандра (табличная, написана на Java, используется Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit и Twitter)
• CouchDB (документ, написанный на Erlang, используемый BBC и Engine Yard)
• Dynomite (ключ-значение, написанный на Erlang, используется Powerset)
• HBase (ключ-значение, написанный на Java, используемый Bing)
• Hypertable (табличный, написанный на C ++, используемый Baidu)
• Кай (ключ-значение, написано на Erlang)
• MemcacheDB (ключ-значение, написанный на C, используется Reddit)
• MongoDB (документ, написанный на C ++, используемый Electronic Arts, Github, NY Times и Sourceforge)
• Neo4j (график, написанный на Java, используемый некоторыми шведскими университетами)
• Проект Voldemort (ключ-значение, написанный на Java, используемый LinkedIn)
• Redis (ключ-значение, написанный на C, используется Craigslist, Engine Yard и Github)
• Riak (ключ-значение, написанный на Erlang, используется Comcast и Mochi Media)
• Ринго (ключ-значение, написанный на Erlang, используется Nokia)
• Scalaris (ключ-значение, написанный на Erlang, используется OnScale)
• Terrastore (документ, написанный на Java)
• ThruDB (документ, написанный на C ++, используемый JunkDepot.com)
• Tokyo Cabinet / Tokyo Tyrant (ключ-значение, написано на C, используется Mixi.jp (японская социальная сеть))

Я хотел бы знать о конкретных проблемах, которые вы, читатель SO, решили с помощью хранилищ данных, и какое хранилище данных NoSQL вы использовали.

Вопросы:

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

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

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

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

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

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

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

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

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

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

Хранение 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}
]

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

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

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

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

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

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

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

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

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

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

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

CouchDB: тематическое исследование

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

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

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

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);

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

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

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

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

MySQL:

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

Cassandra:

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

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

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

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

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

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

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

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

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

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

1. Couchbase Server 3.0
2. Руководство администратора
3. REST API
4. Руководства для разработчиков

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

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

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

Остин

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

Ранее мы обращались к базе данных Oracle, имеющей миллиарды записей, и производительность была очень неоптимальной. Запросы выполнялись от 8 до 12 секунд, даже после оптимизации с использованием SSD. Следовательно, мы почувствовали необходимость использовать оптимизированную для чтения, ориентированную на аналитику базу данных. С кластерами Vertica за уровнем бережливого сервиса мы могли запускать API с производительностью менее секунды.

Vertica хранит данные в проекциях в формате, который оптимизирует выполнение запроса. Подобно материализованным представлениям, проекции хранят наборы результатов на диске ИЛИ SSD, а не вычисляют их каждый раз, когда они используются в запросе. Проекции предоставляют следующие преимущества:

1. Сжатие и кодирование данных, чтобы уменьшить объем памяти.
2. Упростите распределение по кластеру базы данных.
3. Обеспечить высокую доступность и восстановление.

Vertica оптимизирует базу данных, распределяя данные по кластеру с помощью сегментации.

1. Сегментация размещает часть данных на узле.
2. Он равномерно распределяет данные по всем узлам. Таким образом, каждый узел выполняет часть процесса запроса.
3. Запрос выполняется в кластере, и каждый узел получает план запроса.
4. Результаты запросов агрегируются и используются для создания выходных данных.

Для получения дополнительной информации, пожалуйста, обратитесь к документации Vertica @ https://www.vertica.com/knowledgebase/