LINUX.ORG.RU

SQL vs NoSQL

 , , , что-то пошло не так


0

2

Краткая история: программист переписал бэкенд с mysql+django на rethinkdb+nodejs, а быстрее не стало (хотя и решило другие проблемы). Я начал разбираться и обнаружил внутри... всё те же таблицы, join-ы и ORM. А всё потому что один документ не может ссылаться на другой. Максимум что можно сделать это использовать join между таблицами по уникальному id. В результате сбор данных превращается в феерической длины запросы и тормозааа.

У меня два вопроса: 1) а почему на уровне БД нельзя сделать что-то вроде ссылочного типа данных? Указатель какой-нибудь, как в объектных базах данных (они ещё живы?). Я предвижу сложности, но, имхо, это must have.

2) Мы готовим nosql как-то неправильно или в принципе от таблиц никуда не убежать? Я обсуждал проблему с другими разработчиками, они сказали в том или ином виде достаточно часто приходится городить «sql для бедных». Что думаете?

Разделение на таблицы позволило значительно облегчить трансформацию базы при добавлении/изменения функционала. Что ожидаемо, но оказалось гораздо важнее для программистов чем я думал.

★★★★★

Чтобы использовать носкуль нужно быть аюсолютно железобетонно уверенным, что либо между данными никогда не будет ссылок, либо что их актуальность не важна.

Короче если у вас что-то тормозило нужно было просто найти что и заоптимизировать. А при носкуль подходе нужно сильно пересматривать архитектуру.

1. Уже есть в реляционных СУБД

2. Если носкуль не вписывается в задачи, то как его не готовь ничего хорошего обычно не выходит.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)

Потому что как ни крути, а реляционные данные глупо запихивать в хранилище «ключ-значение».

oskar0609
()

Сорри, я в этом не шарю, но судя по

В начале 2000-х годов Google построил свою высокомасштабируемую поисковую систему и приложения: GMail, Google Maps, Google Earth и т. п., решая проблемы масштабируемости и параллельной обработки больших объёмов данных. В результате была создана распределённая файловая система и распределённая система координации, хранилище семейств колонок (англ. column family store), среда выполнения, основанная на алгоритме MapReduce

тут основной профит по скорости достигается возможностью распараллеливания. Поэтому, не может быть такого, что нет выигрыша в скорости. Значит что-то не так организовано архитектурно, скорей всего.

filequest
()
Ответ на: комментарий от filequest

что-то не так организовано архитектурно

Всё верно — наш сценарий не использует сильные стороны nosql, зато использует слабые.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

мне бы хотелось видеть ключ->ссылка

Ключ-ссылка это уже РСУБД. Здесь нужны реляционные СУБД. Можно как угодно изгаляться, выносить логику в код и юзать NoSQL для работы с реляционными данными, но для этого придумали РСУБД. Побуду кэпом: relation (анг. «отношение»), это отношение между таблицами в СУБД. Хранилище ключ-значение предназначено для другого, хотя его теперь модно вкорячивать куда угодно. Модно, стильно, молодежно же. Попса одним словом.

oskar0609
()
Ответ на: комментарий от oskar0609

Почему nosql это сразу «ключ->значение»? Я думал nosql это всё что не использует sql и, скажем, плоские таблицы.

true_admin ★★★★★
() автор топика

Оффтоп: а что слышно про графовые БД? Есть что-то годное не для ручной работы с данными, а для кровавого продакшена?
Многие системы очень удобно представлять как графы, во всяком случае мне.

MrClon ★★★★★
()
Ответ на: комментарий от true_admin

Такое название прижилось. Судя по всему исходно имели в виду нереляционные субд. Отчасти это объясняет трансормацию расшифровки с «не сукль» до «не только скуль».

ya-betmen ★★★★★
()
Ответ на: комментарий от MrClon

а что слышно про графовые БД?

Не знаю, щас сижу читаю про neo4j... Я ещё слышал об OrientDB, об остальных даже и не слышал. Обе на java, никто из моих знакомых не использует. Надо бы на лоре спросить. Спроси, а? :)

Я ещё боюсь того что раз их мало кто использует то мало ли какие там грабли зарыты и ждут своего часа.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

neo4j это точно не про продекшен, это про «удобно ковырять данные вручную» или около того. Там гуй встроенный, что уже символизирует. Ну и производительностью разрабы вроде не слишком заморачивались.

MrClon ★★★★★
()
Ответ на: комментарий от oskar0609

Побуду кэпом: relation (анг. «отношение»), это отношение между таблицами в СУБД.

Не угадал: в теории это отношение между типами данных (атрибутами). Грубо говоря, таблица сама является отношением.

amm ★★
()

почему на уровне БД нельзя сделать что-то вроде ссылочного типа данных? Указатель какой-нибудь, как в объектных базах данных (они ещё живы?). Я предвижу сложности, но, имхо, это must have.

А как ссылочный тип ускорит работу с данными? Будет тот же поиск по скрытому идентификатору. Облегчит написание запросов? Тоже от языка зависит.

amm ★★
()

Можно сказать лишь одно: бггггггггг.

Deleted
()

или в принципе от таблиц никуда не убежать? Я обсуждал проблему с другими разработчиками, они сказали в том или ином виде достаточно часто приходится городить «sql для бедных».

Ну наконец-то.

У людей, не почувствовавших, что даёт SQL, очень часто возникает впечатление, что он их ограничивает, и что отказавшись от реляционной модели, они приобретут невероятную гибкость. Фигушки. Это просто перенос сложности с этапа проектирования на этап кодирования. С ненулевой вероятностью превращения всего это в кошмар на этапе сопровождения.

// Сам когда-то убивал время на создание супер-пупер универсальной надстройки над СУБД. К счастью, вовремя бросил.

hobbit ★★★★★
()
Ответ на: комментарий от erzenteded

далеко не все программисты знают sql

А нужно ли? Я SQL знал только в универе, для сдачи экзамена нужно было набрать N баллов на каком-то сайте (типа sql.ru, уже не помню). С тех пор всё через ORM делал :). Ну, если надо, я вспомню (миграции вот писал для джанги), но так оно, имхо, нафиг не надо.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от amm

Будет тот же поиск по скрытому идентификатору

Я в последние два дня только об этом и думаю. У меня нет ответа на этот вопрос, я поэтому и создал тред чтобы обсудить. Со своей ламерской колокольни я вижу это так.

Если у нас есть прямой указатель на то где лежат related данные то их можно сразу брать по «указателю». Когда же мы делаем join то движок там бурлит по индексам итп. И хотя это как бы должно быть быстро... у нас 20-30 сущностей в базе (плюс служебные таблицы для всяких many-to-many), делая кучу join-ов в один запрос который вытаскивает всё-всё-всё из базы выполняется 0.5с. И я пытаюсь понять можно ли это как-то ускорить. Сильно глубоко не копал, план выполнения не смотрел, но собираюсь серьёзно заняться как только будет время.

true_admin ★★★★★
() автор топика

1 Можно. Видел на примере надстройки над oracle - PL/PLUS от ЦФТ. Кстати так называемые объектные БД - это реляционные с поддержкой пользовательских типов данных. 2 имхо без таблиц не обойтись, наиболее удобная абстракция.

WhiteClick
()
Ответ на: комментарий от true_admin

Потому как join это цикл, чем меньше вложенных join-ов, тем луче. Присмотрись к unit. И да, если запрос «вытаскивает всё-всё-всё из базы» то что-то тут явно не так спроектировано\реализовано.

oskar0609
()
Последнее исправление: oskar0609 (всего исправлений: 1)
Ответ на: комментарий от erzenteded

А тебе, «труЪадмину»™ не будет впадлу переносить всё это гигантское хозяйство на другую датабазу? А начальству нужен этот риск? Мало-ли что при переносе встанет колом. И терять бабки на простое.
Ну ты понял, что чуваки верны принципу: «Работает? Вот и ладушки! И не суй сюда свой свиной пятак.», – не будем этой любящей паре вклинивать psql и провоцировать возникновение любовного треугольника.

Hertz ★★★★★
()
Ответ на: комментарий от hobbit

Золотые слова! Молодёжь, мотайте на ус!

Hertz ★★★★★
()
Ответ на: комментарий от oskar0609

Потому как join это цикл

Ммм, точно? Я думал оно должно взять нужные значения по индексам. Иначе это будет треш и угар по скорости...

Присмотрись к unit

Что это?

true_admin ★★★★★
() автор топика
Ответ на: комментарий от Hertz

тенденция впаривать вместо поддержки от оракла (пусть она и стоит как самолет) поддержку от кучки эрзентов, юридически никак с самим постгресом не связанных? ну так лох не мамонт (каламбур не преднамеренный)

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Тоже логично. Кучка эрзентов и такую мимими как Postgres влёт смогут испоганить (вернее, её репутацию), и позиции Оракуля только усилятся на рынке.

Hertz ★★★★★
()
Ответ на: комментарий от true_admin

Как оптимизатор решит, так и будет.

Deleted
()
Ответ на: комментарий от vostrik

Вспомнил и ржу чуть не до слёз, как dk- материл Эрзента, чтобы тот, когда пытался попасть на работу в Альфабанк, «убрал свои кудрявые руки от МОЕГО банка!».

Hertz ★★★★★
()
Ответ на: комментарий от true_admin

что это

Тьфу, unioun же

будет треш и угар по скорости

Много вложенных join-ов это всегда треш по скорости, даже по индексным полям. Неплохая статья про JOIN-ы, хоть и швабр.

oskar0609
()
Ответ на: комментарий от true_admin

Если у нас есть прямой указатель на то где лежат related данные то их можно сразу брать по «указателю».

Прямой указатель — это смещение в файле? Такой способ хранения серьезно ограничивает возможности изменения данных и администрирования БД. Если что-то другое, то для nosql баз id — это и есть такой указатель.

один запрос который вытаскивает всё-всё-всё из базы выполняется 0.5с.

Для всех данных немного.

amm ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.