Итак, я закончил свою первую полную неделю на новой работе, и я узнал много нового. Это здорово, потому что именно поэтому вы меняете работу.
Я много узнаю об этих новомодных
вещах в базе данных NoSQL . Архитектура
LMAX была основана на хранении всего в памяти и сокращении времени ожидания ввода-вывода — сообщения записывались на диск, а операции чтения и записи в базу данных MySQL выходили за пределы критического пути. Поэтому делать что-то радикальное с архитектурой хранилища просто не было в списке приоритетов.
Все, что я знал о NoSQL, я узнал на различных конференциях, на которых я собирался в прошлом году, и даже тогда он ограничен — без каких-либо деловых оснований для получения знаний я знаю, что он просто вытечет из моего мозга, поэтому я избегаю сеансы без непосредственной применимости ко мне.
Давайте подведем итог, что я знал о базах данных NoSQL до прошлой недели:
- Они не используют SQL. Кто знал?
- Есть разные вкусы. Есть графическое и ключевое значение и … другие …
- Они «масштабируемы» (да, да, это веб-масштаб ).
- Некоторые / многие / все (?) Придерживаются идеи возможной последовательности
Я с подозрением относился к шумихе вокруг NoSQL, отчасти потому, что это связано с бессмысленным маркетинговым термином «Большие данные», а отчасти потому, что я циник, который насмехается над вещами, которые становятся слишком популярными. Вот что я думаю, когда слышу следующие термины:
- Облако — увольняй людей из своей системы и забрось свою комнату связи!
- Большие данные — анализируйте Твиттер, чтобы узнать, как читать мысли ваших клиентов!
- NoSQL — перестань платить Oracle!
- Функционально — мы не могли достаточно хорошо освоить основные языки программирования, поэтому мы переключились на что-то более сложное!
Я не знаю, полезно ли быть таким циничным, но я слишком стар, чтобы прыгать на всех встречах.
Во всяком случае . Вернемся к людям, которые сейчас оплачивают мои счета.
К сожалению, отсутствие SQL — это то, что поразило воображение, а не отсутствие таблиц и реляционной структуры. SQL никогда не был (на мой взгляд) чем-то особенно злым, это довольно хороший язык для того, чтобы сказать: «Я хочу этот материал из этого места, который соответствует этим критериям», и это то, что мы собираемся сделать в какой-то момент, независимо от того, технологии.
Гораздо важнее, что структура данных отличается в базах данных NoSQL.
В традиционных реляционных базах данных у вас есть таблицы, и связи между этими таблицами достигаются с помощью внешних ключей. Я начинаю думать о них как о чем-то вроде решетки со связями между ними:
 |
| Серия таблиц базы данных и их взаимосвязи. Честный. |
(Да, я снова экспериментирую. На этот раз с новым блестящим iPad, стилусом и
Penultimate . Он хорош для специальных рисунков, но ему не хватает точности графического планшета и гибкости GIMP).
На очень высоком уровне кажется, что существует четыре (ish) типа баз данных NoSQL:
- Семейство колонн
- Key / Value
- график
- Документ
столбцов Базы данных семейства столбцов кажутся мне новичком в этой области, похожим на ключ / значение, о котором я расскажу. Я в основном слышал, как
Кассандра использовалась в качестве примера этого типа базы данных NoSQL. Я думаю, что то, что я думаю об этом, и, конечно, я могу ошибаться / чрезмерно упрощать, это уникальный ключ, связанный с набором ключей / значений:
ID: 63537 Name: Trisha Twitter: @trisha_gee Location: London
Который я перевожу в группы пар ключ / значение, с идентификатором в качестве своего рода заголовка:
 |
| Пары ключ / значение, сгруппированные по идентификатору |
Вам нужен ключ, чтобы найти все детали обо мне. Насколько я понимаю, он отлично подходит для записи данных, но он менее гибок для специальных запросов.
Ключ / значение.
Эти типы баз данных NoSQL (например,
Riak ) в значительной степени не содержат схем, поскольку вы просто получаете в них пары ключей и значений. Если честно, лучшее описание, которое я нашел, было на
dba.stackexchange.com , поэтому я не собираюсь переписывать его с моим (на данный момент) ограниченным пониманием.
 |
| Бесконечные списки ключей / значений |
Из того, что я слышал до сих пор, базы данных Key / Value и семейства столбцов обеспечивают
конечную согласованность . Я не знаю, сколько из этого зависит от их модели данных и сколько определяется отдельными продуктами. Для некоторых людей окончательная согласованность нарушает правила, но во многих случаях мне кажется, что это всего лишь вопрос, как разобраться в этом и правильно разработать приложение.
График
Я наткнулся на базы данных графиков, когда наткнулся на
Neo4j , поболтав там с некоторыми очень умными парнями. Графовая база данных позволяет вам моделировать ваши данные в виде серии узлов и связей. И если я думаю об этом, это не огромный шаг ни от реляционных моделей,
ни отобъектные модели. Это не просто применимо к области социальных сетей (где очень легко думать с точки зрения пользователей и их отношений), на самом деле многие вещи, которые мы проектируем, могут быть смоделированы таким образом. Не используя его, я не уверен, сколько умственного прыжка вам нужно сделать, чтобы начать думать таким образом, но кажется, что он может быть подходящим для многих проблем.
 |
| График узлов с аннотированными связями |
Мне было бы интересно узнать, каковы архитектурные компромиссы в использовании этой модели.
Документ
Теперь MongoDB попадает в четвертую категорию, база данных документов. И, как NoSQL n00b , теперь это продукт и область, о которых я знаю больше всего, и, несомненно, я буду более взволнован, так как 10gen внушают мне идею MongoDB.
Документы представляют собой привычную структуру для разработчиков, особенно если они работают с JSON. Итак, документ может быть:
{
name: "Trisha",
twitter: "@trisha_gee",
address: [
{ line1: "not telling",
line2: "no really",
town: "London" }
]
}
Для меня это выглядит так, как будто это сопоставляется с моей объектной моделью в форме домена легче, чем с реляционной базой данных, которая всегда требует своего рода OR-сопоставления (независимо от того, делаете ли вы это с помощью hibernate или используете Spring, чтобы сделать это самостоятельно, вы все равно отображение таблиц в объекты и наоборот). Что мне нравится в формате документов, так это вложенные вложенные документы для данных, которые принадлежат друг другу. В реляционных базах данных вы все равно в конечном итоге денормализуете производительность, так почему бы просто не принять это заранее и не использовать как часть того, что вы храните?
Это, конечно, имеет свою стоимость — ничто не обходится без компромиссов. Каждый раз, когда вы запрашиваете этот документ, вы получаете всю сумму. Вы не можете иметь человека без адреса. Итак, вам нужно понять отношения (все еще) и то, хотите ли вы, как правило, получать все эти данные одновременно или хотите ли вы сделать два отдельных вызова.
Что подводит меня к другой вещи, знакомой по реляционным дням — внешним ключам. Поле в вашем документе может быть идентификатором другого документа, поэтому вы можете переходить по ссылкам и получать другие документы, связанные с начальным. Опять же, здесь есть компромиссы — каждая ссылка, по которой вы переходите, представляет собой отдельный запрос к базе данных. Эти запросы к базе данных могут быть очень быстрыми, но если вам нужны эти данные каждый раз, вы, вероятно, захотите, чтобы они были включены в ваш первый документ для сохранения дополнительного вызова. Я предполагаю, что на самом деле это вопрос латентности и пропускной способности — один запрос, который возвращает крупногабаритный документ, или несколько запросов, которые возвращают меньшие.
Таким образом, дизайн схемы все еще важен в базах данных документов, даже если у вас нет реляционной схемы. Никакая новая технология не может служить оправданием, чтобы перестать думать о проблеме, которую вы пытаетесь решить, и понять компромиссы в дизайне.
Кажется, одним из преимуществ чего-то вроде MongoDB над некоторыми базами данных ключ / значение является возможность писать специальные запросы и настраиваться на них. Данные структурированы (они находятся в документе), и они не должны каждый раз находиться в одной и той же структуре — не каждому документу, касающемуся человека, нужны все поля, которые мог бы иметь другой человек. Но вы все равно можете запросить людей, у которых есть синие автомобили, или людей, которые живут в Лондоне, или людей, чьи фамилии начинаются с G. Если вы обнаружите, что делаете один и тот же запрос несколько раз, вы можете добавлять индексы в MongoDB так же, как вы это делаете. реляционная база данных.
Кажется, я углубляюсь в подробности MongoDB, поэтому я остановлюсь здесь и оставлю это на другой раз.
В итоге
Классификация целого ряда продуктов как «NoSQL» вводит в заблуждение и вводит в заблуждение. Единственное, что у них общего, — это то, что они не являются традиционными реляционными базами данных. Помимо этого, некоторые из них так же отличаются друг от друга, как и от реляционных баз данных. Я даже не упомянул технологии кэширования — эти продукты имеют функциональность, которая также пересекается с базами данных NoSQL. Но даже тогда цели несколько иные, и даже не взаимоисключающие.
Как и во всем, очень важно понимать сильные и слабые стороны технологии и требования вашей области. Эти разные способы организации данных и разные продукты будут работать действительно хорошо в определенных обстоятельствах и довольно плохо при использовании в других. Получение понимания того, каковы эти сильные и слабые стороны, будет важно при принятии правильных решений по продукту / архитектуре / дизайну.
Ничто из этой информации не является новым, в Интернете много материала о различных типах баз данных NoSQL. Я пишу это больше для моей же пользы, чем что-либо еще, моя память печально известна. Для более глубокого (и, возможно, более точного чтения) есть:
- NoSQL дистиллированного Мартина Фаулера
- … и его введение в предмет
- Тим Берглунд (@tlberglund) сделал большой обзор трех типов на JAX London на прошлой неделе. Там есть видео того же содержания (разные конференции) здесь .
- http://nosql-database.org/, кажется, перечисляет все продукты, которые подпадают под огромный зонтик, но не являются наиболее пригодными для использования сайтами.
- И да, я использовал Википедию. Что, вероятно, где я ошибся …
