Возможности MongoDB / NoSQL


видеозаписи с конференции Mongo Moscow.
Вот тезисы о возможностях, оставшиеся от просмотренного.
Перевод был не ахти, смотрел на английском, мог что-нибудь напутать.
Старался быть объективным, если не получилось — пишите :)



  1. Данные в MongoDB — список хешей JSON, со вложенными массивами и хешами.
  2. Документ — это один такой хеш.
  3. Поэтому и нет ALTER TABLE — структуры записей не зависят друг от друга.
  4. Collations сейчас поддерживаются плохо, UTF — хорошо.
  5. Поразил синтаксис местами: В MongoDB пишут 'db.schema.find ( { «s», { $gt: «a» } } )' вместо 'where s > «a»'.
  6. Нет транзакций. Зато операции над документами гарантированно атомарны.
  7. При вызове getLastError проверяется, не возникла ли ошибка. В safe mode (во многих драйверах стоит по умолчанию) вызывается после каждой записи. Можно вызывать реже — меньше оверхед, но в случае ошибки придется перезаписать сразу пачку записей.
  8. getLastError можно ожидать не от всех серверов, а только от нескольких.
  9. Документы они предлагают создавать достаточно сложными (например, один документ — это блог с вложенными постами, каждый — со вложенным деревом комментов). Это имхо хреновая идея — нагрузка на один элемент может стать критически большой.
  10. Нет JOIN. Просто создавайте структуру данных так, чтобы он вам не понадобился. Мыши, станьте ежиками.
  11. Есть репликация, репликационный лог (не знаю, бинарный или командный).
  12. Если мастер репликации умер, среди слейвов через 10-20 с будет выбран новый.
  13. Есть шарды. По диапазонам, а не по хешам. Диапазоны для каждого шарда задаются в конфиге.
  14. Решардинг ведется корректировкой этих диапазонов. При этом записи на изменяемые шарды блокируются на время переноса.
  15. Данные в сторадже разбиваются по чанкам примерно по 200М.
  16. Есть MapReduce интерфейс, но про него только мельком упомянули.
  17. Есть spatial индексы.
  18. Есть mmapped storage с настраиваемой частотой fsync.
  19. Создалось впечатление, что индексы они держат только в памяти, но, возможно, это и не так. Не хотелось бы.
  20. Индексы — некие деревья, похожие на B-tree. Их лучше периодически перестраивать, но с версии 1.8 — достаточно редко.
  21. Интересно — в фильтрах запроса можно задавать условие $where и в нем писать условие фильтра на JS.
  22. Правда, индексы при этом использоваться не будут (еще бы).
  23. Есть sparse индексы — если атрибут задан только у малого числа документов, в индекс попадут только они.
  24. Covered indexes — это IOT, т.е. индекс содержит и другие атрибуты, для того, чтобы запрос мог вернуть результаты, пользуясь только данными из индекса, без доступа к самим чанкам с документами.
  25. Одна запись в индексе — около 40 байт оверхеда.
  26. Empirical query optimizer, что настораживает.
  27. Оптимизирует отношение index scan к числу возвращаемых документов.
  28. В любом случае, используемый индекс можно задать в хинте.

Комментариев нет:

Отправить комментарий