SQL (MySQL) проти NoSQL (CouchDB) [закрито]

Я в середині розробки високомасштабного додатку, який повинен зберігати багато даних. Наприклад, він буде зберігати багато користувачів, а потім такі речі, як багато їхніх повідомлень, коментарів і т. Д. Я завжди використовував MySQL раніше, але тепер я маю на увазі спробувати щось нове, як couchdb або подібне, що не є SQL.

Хтось має якісь думки чи настанови з цього приводу?

Ось цитата з недавньої публікації в блозі від Dare Obasanjo .

Бази даних SQL схожі на автоматичну передачу, а бази даних NoSQL - як передачі вручну. Перейшовши на NoSQL, ви станете відповідальним за велику роботу, яку система піклується автоматично у реляційній системі баз даних. Подібно до того, що відбувається, коли ви вибираєте механічну коробку передач вручну. По-друге, NoSQL дозволяє досягти більшої продуктивності системи, усуваючи безліч перевірок цілісності, виконаних реляційними базами даних із рівня баз даних. Знову ж таки, це схоже на те, як ви можете отримати більшу продуктивність свого автомобіля, керуючи механічною коробкою передач проти автомобіля автоматичної коробки передач.

Однак найпомітніша схожість полягає в тому, що так само, як і більшість із нас не може реально скористатися перевагами транспортного засобу з механічною коробкою передач, тому що більшість наших водіння сидить у трафіку на шляху до та з роботи, існує подібна сувора реальність оскільки більшість сайтів не відповідають масштабам Google або Facebook, і тому немає потреби в Bigtable або Cassandra.

До якого я можу додати лише те, що перехід з MySQL, де ви маєте хоча б певний досвід, на CouchDB, де у вас немає досвіду, означає, що вам доведеться мати справу з цілим новим набором проблем та вивчати різні концепції та найкращі практики. Хоча саме по собі це чудово (я вдома граю з MongoDB і мені це дуже подобається), це буде витрата, яку потрібно обчислити, оцінюючи роботу для цього проекту, і несе невідомі ризики, обіцяючи невідомі переваги. Дуже важко буде судити, чи зможете ви виконати проект вчасно та з якістю, яку ви хочете / потребуєте для успіху, якщо він базується на технології, яку ви не знаєте.

Тепер, якщо у вас є в колективі експерт у галузі NoSQL, то, безумовно, добре придивіться до цього. Але без будь-якого досвіду команди, не стрибайте на NoSQL для нового комерційного проекту.

Оновлення : Просто кинути трохи бензину у відкритий вогонь, який ви розпочали, ось дві цікаві статті людей з табору SQL. :-)

Я не можу чекати, коли NoSQL помре (оригінальна стаття відсутня , ось копія )
Боротьба з розумом NoSQL, хоча це не анти-NoSQL Piece
Update : Ну ось цікава стаття про NoSQL Maense
Sense of NoSQL

Схоже, що тільки справжні рішення сьогодні обертаються навколо масштабування чи загострення. Усі сучасні бази даних (NoSQL, а також NewSQL) підтримують горизонтальне масштабування прямо з поля, на рівні бази даних, без необхідності в додатку мати код заточування або щось подібне.

На жаль, для надійного доброго старого MySQL не передбачено шардингу "поза коробкою". ScaleBase (відмова від відповідальності: я працюю там) - це виробник повного рішення щодо масштабування, "якщо ви хочете, машина з автоматичним заточуванням". ScaleBae аналізує ваші дані та потік SQL, розподіляє дані по вузлах DB та агрегує під час виконання - так що вам не доведеться! І це безкоштовно скачати.

Не зрозумійте мене неправильно, NoSQL - це чудово, вони нові, нові - це більше вибору і вибір завжди хороший !! Але вибираючи NoSQL, ви маєте ціну, переконайтесь, що ви можете його заплатити ...

Тут ви можете побачити більше даних про MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

Сподіваюся, що це допомогло.

Один з найкращих варіантів - це звернутися до MongoDB (NOSql dB), який підтримує масштабованість. Зберігає велику кількість даних, крім великих даних у формі документів на відміну від рядків і таблиць у sql. гарантувати гарантію даних, що підтримує декілька серверів, що мають основний сервер db як базовий. Мова незалежна. Гнучка у використанні