it-roy-ru.com

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

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

  • Cassandra (табличный, написанный на 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, используемый некоторыми шведскими университетами)
  • Проект Волдеморт (ключ-значение, написанный на Java, используемый LinkedIn)
  • Redis (ключ-значение, написанное на C, используется Craigslist, Engine Yard и Github)
  • Riak (ключ-значение, написанное на Erlang, используется Comcast и Mochi Media)
  • Ринго (ключ-значение, написанное на Erlang, используется Nokia)
  • Scalaris (ключ-значение, написанное на Erlang, используется OnScale)
  • Terrastore (документ, написанный на Java)
  • ThruDB (документ, написанный на C++, используемый JunkDepot.com)
  • Кабинет Токио/Токийский Тиран (ключ-значение, написано на C, используется Mixi.jp (японский сайт социальной сети))

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

Вопросы:

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

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

189
knorv

Я переключил небольшой подпроект с 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) для этого подпроекта, и он хорошо выполняет свою работу.

49
tux21b

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

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

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

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

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

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

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

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

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

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}
]
50
Brian

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

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

Обновление: И выбранная Твиттером Кассандра над несколькими другими, включая HBase, Voldemort, MongoDB, MemcacheDB, Redis и HyperTable.

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

22
Jim Ferrans

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

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

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

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

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

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

8
serbaut

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

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

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

5
TwentyMiles

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

У меня есть клиент с открытым исходным кодом c # 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);
5
mythz

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

4
Michel

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

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

3
peter ode

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

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

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

2
Theo

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

2
GabiMe

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

2
SorcyCat

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

MySQL:

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

Cassandra:

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

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

2
Florent

Я бы посоветовал всем, кто читает это, попробовать 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

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

Остин

1
Austin Gonyou

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

1
Thomas Jaeger

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

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

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

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

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

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

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

0
Vik