Коли використовувати MongoDB або інші системи баз даних, орієнтовані на документи? [зачинено]

Ми пропонуємо платформу для відео- та аудіокліпів, фотографій та векторних графік. Ми почали з MySQL як резервної бази даних і нещодавно включили MongoDB для зберігання всієї метаінформації файлів, оскільки MongoDB краще відповідає вимогам. Наприклад: фотографії можуть містити інформацію Exif , у відео можуть бути аудіозаписи, куди ми також хочемо зберігати метаінформацію. Відео та векторна графіка не поділяють загальної метаінформації тощо, тому я знаю, що MongoDB ідеально підходить для зберігання цих неструктурованих даних та для їх пошуку.

Однак ми продовжуємо розробляти нашу платформу та додавати функції. Тепер одним із наступних кроків буде надання форуму для наших користувачів. Питання, яке зараз виникає: використовувати базу даних MySQL, яка була б хорошим вибором для зберігання форумів і дописів на форумах тощо, чи використовувати для цього також MongoDB?

Отже, питання: коли використовувати MongoDB і коли використовувати RDBMS. Що б ви взяли, mongoDB або MySQL, якби у вас був вибір і чому ви взяли б його?

У NoSQL: Якби це було так просто , автор пише про MongoDB:

MongoDB - це не ключ / цінність, це трохи більше. Це точно також не RDBMS. Я не використовував MongoDB у виробництві, але я його трохи побудував для тестового додатка, і це дуже класна частина комплекту. Це здається дуже ефективним, або або має, або незабаром матиме відмовостійкість і автоматичне посилення (так само воно буде масштабуватися). Я думаю, що Монго може бути найближчим до заміни RDBMS, яку я бачив досі. Він не працюватиме для всіх наборів даних та шаблонів доступу, але він створений для ваших типових CRUD-матеріалів. Зберігання того, що по суті є величезним хешем, і можливість вибору на будь-якій з цих клавіш - це те, для чого більшість людей використовують реляційну базу даних.Якщо ваш БД 3NF і ви не приєднуєтесь (ви просто вибираєте купу таблиць і складаєте всі об'єкти, AKA, що робить більшість людей у ​​веб-додатку), MongoDB, ймовірно, запустить вам дупу.

Потім у висновку:

Справжня річ, на яку слід зазначити, що якщо вас стримують робити щось надзвичайне, оскільки ви не можете вибрати базу даних, ви робите це неправильно. Якщо ви знаєте mysql, просто використовуйте його. Оптимізуйте, коли вам насправді потрібно. Використовуйте його як магазин ак / в, використовуйте його як rdbms, але заради бога, створіть свою програму-вбивцю! Нічого цього не має значення для більшості програм. Facebook все ще багато використовує MySQL. У Вікіпедії дуже багато використовується MySQL. FriendFeed багато використовує MySQL. NoSQL - чудовий інструмент, але це, безумовно, не буде вашою конкурентоспроможною програмою, це не стане робити вашу програму гарячою, і, більш за все, ваші користувачі не будуть піклуватися ні про що з цього.

На чому я буду будувати свій наступний додаток? Ймовірно, Postgres. Чи буду використовувати NoSQL? Можливо. Я також можу використовувати Hadoop і Hive. Я можу зберігати все в плоских файлах. Можливо, я почну ламати Маглева. Я буду використовувати все, що найкраще для роботи. Якщо мені потрібно звітувати, я не буду використовувати жоден NoSQL. Якщо мені потрібно кешування, я, мабуть, використовую Tokyo Tyrant. Якщо мені потрібна ACIDity, я не буду використовувати NoSQL. Якщо мені потрібна тонна лічильників, я буду використовувати Redis. Якщо мені потрібні транзакції, я буду використовувати Postgres. Якщо у мене є тонна одного типу документів, я, мабуть, буду використовувати Монго. Якщо мені потрібно писати 1 мільярд об’єктів на день, я, мабуть, використовую Волдеморта. Якщо мені потрібен повний пошук тексту, я, мабуть, використовую Solr. Якщо мені потрібен повнотекстовий пошук енергонезалежних даних, я, мабуть, використовую Sphinx.

Мені подобається ця стаття, я вважаю її дуже інформативною, вона дає хороший огляд пейзажу та шуму NoSQL. Але, і це найважливіша частина, вона дійсно допомагає задавати собі правильні питання, коли мова йде про вибір між RDBMS і NoSQL. Варто прочитаного ІМХО.

Альтернативне посилання на статтю

Після двох років використання MongoDb для соціального додатку я був свідком того, що насправді означає жити без SQL RDBMS.

1. Ви закінчуєте писати завдання, щоб робити такі речі, як об'єднання даних з різних таблиць / колекцій, що RDBMS зробить для вас автоматично.
2. Ваші можливості запиту за допомогою NoSQL різко калічені. MongoDb може бути найближчим до SQL, але він все ще сильно відстає. Довірся мені. SQL-запити надзвичайно інтуїтивні, гнучкі та потужні. MongoDb запитів немає.
3. Запити MongoDb можуть отримати дані лише з однієї колекції та скористатися лише одним індексом. І MongoDb - це, мабуть, одна з найбільш гнучких баз даних NoSQL. У багатьох сценаріях це означає більше зворотних поїздок на сервер для пошуку відповідних записів. І тоді ви починаєте денормалізувати дані - це означає фонові завдання.
4. Той факт, що це не реляційна база даних, означає, що ви не матимете (вважається, що хтось погано спрацьовує) зовнішніх ключових обмежень для забезпечення відповідності ваших даних. Запевняю, що врешті-решт це створить невідповідності даних у вашій базі даних. Будь готовий. Швидше за все, ви почнете писати процеси чи перевірки на відповідність своїй базі даних, що, ймовірно, не буде краще, ніж дозволити RDBMS робити це за вас.
5. Забудьте про зрілі рамки на кшталт сплячки.

Я вважаю, що 98% всіх проектів, ймовірно, набагато кращі з типовим SQL RDBMS, ніж з NoSQL.

для зберігання цих неструктурованих даних

Як ви вже говорили, MongoDB найкраще підходить для зберігання неструктурованих даних. І це може організувати ваші дані у форматі документа. Ці альтернативи RDBMS, які називаються сховищами даних NoSQL ( MongoDB , CouchDB , Voldemort ), дуже корисні для додатків, які масштабують масштаби та потребують швидшого доступу до даних з цих великих сховищ даних.

І реалізація цих баз даних простіша, ніж звичайні RDBMS. Оскільки це прості бінарні об'єкти в стилі документа або двосторонні документи, безпосередньо серіалізовані на диск. Ці сховища даних не застосовують властивості ACID та будь-які схеми . Це не забезпечує жодних можливостей для транзакцій . Таким чином, це може бути масштабним, і ми можемо досягти більш швидкого доступу (і читати, і писати).

Але навпаки, RDBM застосовує ACID та схеми для даних. Якщо ви хочете працювати зі структурованими даними, ви можете перейти до RDBM.

Я б вибрав MySQL для створення форумів для подібних матеріалів. Тому що це не буде масштабуватися великим. І це дуже простий (звичайний) додаток, який має структуровані відносини між даними.

Зауважте, що Монго фактично зберігає JSON. Якщо ваш додаток має справу з великою кількістю об'єктів JS (з вкладкою), і ви хочете зберегти ці об'єкти, то існує дуже сильний аргумент щодо використання Mongo. Це робить ваші шари DAL та MVC надто тонкими, оскільки вони не розпаковують усі властивості об'єкта JS і намагаються примусити їх вписати їх у структуру (схему), до якої вони, природно, не вписуються.

У нас є система, що має в основі кілька складних об'єктів JS, і ми любимо Монго за те, що можемо наполегливо все наполегливо, дуже легко. Наші об'єкти також досить аморфні та неструктуровані, і Монго вбирає це ускладнення, не моргаючи. У нас є спеціальний шар звітності, який розшифровує аморфні дані для споживання людиною, і це було не так складно.

Я б сказав, що використовуйте RDBMS, якщо вам потрібні складні транзакції. Інакше я б пішов з MongoDB - більш гнучким для роботи, і ви знаєте, що він може масштабувати, коли вам потрібно. (Однак я упереджений - працюю над проектом MongoDB)

Кому потрібні розподілені, роздрібнені форуми? Можливо, Facebook, але якщо ви не створюєте конкурента у Facebook, просто використовуйте Mysql, Postgres або все, що вам найбільше подобається. Якщо ви хочете спробувати MongoDB, добре, але не сподівайтеся, що це зробить магію для вас. У ньому будуть свої химерності та загальна гнучкість, як і все інше, оскільки я впевнений, що ви вже виявили, чи справді вже працювали над цим.

Звичайно, MongoDB може бути розкритим і здається легким на поверхні, але ви зіткнетесь з проблемами, які вже подолали більш зрілі продукти. Не заманюйте так легко, а скоріше зачекайте, поки "nosql" дозріє або не помре.

Особисто я думаю, що "nosql" в'яне і помре від роздробленості, оскільки немає встановлених стандартів (майже за визначенням). Тому я особисто не ставлю на це жодних довгострокових проектів.

Єдине, що може зберегти "nosql" у моїй книзі, це якщо вона може інтегруватися в Ruby або подібні мови безперешкодно, а також зробити мову "стійкою", майже не маючи накладних витрат у кодуванні та дизайні. Це може статися, але я зачекаю до тих пір, не зараз, і це, звичайно, має бути більш зрілим.

Btw, чому ти створюєш форум з нуля? Є багато форумів з відкритим кодом, які можна налаштувати під більшість вимог, якщо ви справді не створюєте Форуми нового покоління (що я сумніваюся).

Я бачив у багатьох компаніях, які використовують MongoDB для аналітики в реальному часі з журналів додатків. Його безпроблемна схема дійсно підходить для журналів додатків, де схема запису має тенденцію змінюватись час від часу. Крім того, його функція Capped Collection є корисною, оскільки вона автоматично очищає старі дані, щоб зберегти дані в пам'яті.

Це одна сфера, на яку я дійсно думаю, що MongoDB підходить, але MySQL / PostgreSQL більше рекомендується. В Інтернеті дуже багато документальних та програмних ресурсів, а також їх функціональності та надійності.

Дві головні причини, чому ви хочете віддати перевагу Монго, - це

• Гнучкість в дизайні схем (зберігання документів типу JSON).
• Масштабованість - Просто додайте вузли, і вона може гарно горизонтально масштабуватися.

Він підходить для великих даних. RDBMS не корисний для великих даних.

Ви знаєте, все це про приєднання та "складні транзакції" - але саме Монті багато років тому пояснив "потребу" в COMMIT / ROLLBACK, сказавши, що "все, що робиться в класах логіки (а не база даних) у будь-якому разі '- значить, все те саме і знову. Потрібно - німий, але неймовірно охайний та швидкий механізм зберігання / пошуку даних, для 99% того, що роблять веб-програми.

Як було сказано раніше, ви можете вибрати між багатьма варіантами, поглянути на всі ці варіанти: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Я пропоную знайти найкращу комбінацію: MySQL + Memcache - це справді чудово, якщо вам потрібен ACID і ви хочете приєднатися до деяких таблиць. MongoDB + Redis ідеально підходить для зберігання документів. Neo4J ідеально підходить для бази даних графіків

Що я роблю: я починаю з MySQl + Memcache, тому що я звик, потім починаю використовувати рамки інших баз даних. У одному проекті ви можете об'єднати, наприклад, MySQL та MongoDB!