Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53041
Eugene New
H5N1, вот вы конкретно утверждали, что реляционную базу надо использовать как хранилище, тянуть все на app-server и там обрабатывать и что так будет быстрее. Давайте примерчик, чтобы не быть голословным.

Я заранее скажу чем это закончится. 100500 раз в интернетах поднимались темы сравнения СУБД
и движков которые кто-то закодил на коленке.

У этих тем есть один главный недостаток. Не очерчен наиболее общий юзкейс. Грубо говоря автор
был прав когда говорит что доступ к хеш-аррею быстрее чем к DBMS. Но перед этим... перед тем
как спорить надо нарисовать некое техническое задание в виде кейсов перформанса и огласить
правила судейства. И вот на этой точке все ораторы сливались.

Погуглите архивы по ключевому слову Стебелек.
2 окт 18, 12:57    [21692512]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
H5N1
Eugene New
H5N1, вот вы конкретно утверждали, что реляционную базу надо использовать как хранилище, тянуть все на app-server и там обрабатывать и что так будет быстрее. Давайте примерчик, чтобы не быть голословным.


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

это от бедности. Ну нельзя же всерьез считать что экспорт из БД террабайта в текстовый файл а потом его обработка питоном - это эффективнее чем обработка внутри бд.
2 окт 18, 12:58    [21692514]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Симонов Денис
Eugene New,

он нигде такого не утверждал. Каждой технологии свой место. Да и по поводу вытеснения SQL я с ним не согласен. Оно вытесняется ровно там где это плохо работает, где работает хорошо там сидит прочно.

плохо работает там где нету связанных данных. Как только данные появляются связанные, разные сущности с FK и т.п. сразу же SQL оказывается эффективен
2 окт 18, 13:03    [21692520]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53041
Ivan Durak
Симонов Денис
Eugene New,

он нигде такого не утверждал. Каждой технологии свой место. Да и по поводу вытеснения SQL я с ним не согласен. Оно вытесняется ровно там где это плохо работает, где работает хорошо там сидит прочно.

плохо работает там где нету связанных данных. Как только данные появляются связанные, разные сущности с FK и т.п. сразу же SQL оказывается эффективен

+OLTP, транзакции и блокировки... и бич всего энтерпрайза - изменения и новые user-stories.
2 окт 18, 13:04    [21692523]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
террабайта в текстовый файл а потом его обработка питоном


Это тем питоном, который интерпретируемый медленный язык? И сколько лет времени занимает обработка им терабайта?
2 окт 18, 13:04    [21692524]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53041
Eugene New
террабайта в текстовый файл а потом его обработка питоном


Это тем питоном, который интерпретируемый медленный язык? И сколько лет времени занимает обработка им терабайта?

Там ... скорее всего Питон просто обёртка над native библикотекой которая и делает весь machine-learning.
Такая практика есть.

Тоесть питон там ничего не делает а просто стоит в интерфейсной части вызовов.
2 окт 18, 13:06    [21692525]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5021
H5N1
... гораздо разумней тащить данные из sql наружу и там нормальным апп сервером молотить, оставляя sql роль тупого сториджа. со всеми вытекающими к перфоменсу.

Благодаря таким "разумным" у ДБА всегда будет много работы, чтобы потом исправлять все это за вами на проектах с большим кол-вом данных. :)
2 окт 18, 14:55    [21692751]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
Megabyte
H5N1
... гораздо разумней тащить данные из sql наружу и там нормальным апп сервером молотить, оставляя sql роль тупого сториджа. со всеми вытекающими к перфоменсу.

Благодаря таким "разумным" у ДБА всегда будет много работы, чтобы потом исправлять все это за вами на проектах с большим кол-вом данных. :)


благодаря мне АДБ уволены, а данные никуда не гоняются, т.к. процесятся на хадупе в параллель. а вот у бедняг с ораклом тупо нет вариантов. абсолютно все Ынтерпрайз решения тянут данные из рсубд, потому как какой-нибудь tensorflow модель натренировать в рсубд никак. и бедняги тянут, а потом еще и просчитывают результ от натренированной модели долбя rest вызовами какой-нить сервис. опять, от безысходности.
2 окт 18, 15:45    [21692857]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
абсолютно все Ынтерпрайз решения тянут данные из рсубд, потому как какой-нибудь tensorflow модель натренировать в рсубд никак


Так абсолютно все или какой-нибудь? Проведите границу применимости своего метода. Ну там для обучения нейронных сетей или еще чего то, неспособного использовать sql-запросы. Потому что вы говорите так, что создается ложное ощущение универсальности вашего подхода.
2 окт 18, 16:06    [21692898]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3070
Eugene New
3. Возможно считается, что среднестатистический программист настолько туп и не обладает способностями к абстрактному мышлению, что не в состоянии понять реляционную теорию, основанную на понятии множеств.

Модератор: Удалено


Сообщение было отредактировано: 2 окт 18, 16:46
2 окт 18, 16:16    [21692918]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53041
H5N1
Megabyte
пропущено...

Благодаря таким "разумным" у ДБА всегда будет много работы, чтобы потом исправлять все это за вами на проектах с большим кол-вом данных. :)


благодаря мне АДБ уволены, а данные никуда не гоняются, т.к. процесятся на хадупе в параллель. а вот у бедняг с ораклом тупо нет вариантов. абсолютно все Ынтерпрайз решения тянут данные из рсубд, потому как какой-нибудь tensorflow модель натренировать в рсубд никак. и бедняги тянут, а потом еще и просчитывают результ от натренированной модели долбя rest вызовами какой-нить сервис. опять, от безысходности.

Хадуп и Оракл это разные классы систем. Их use-cases пересекаются очень в малом множестве.
И если вы нашли применение Хадуп-у - то это круть. И вы - хороший архитектор по данным.
Но Хадуп не может заменить Оракл на обработке оперативных данных.

Поэтому ваш тезис нужно дополнять. В противном случае новички которые придут
в этот топик и прочитав ваш пост могут сделать неверные выводы. Хуже того
они пойдут в другие топики и будут реплицировать своё заблудение порождая
слухи и мистификации вокруг хадупа который вообще инструмент нишевый
и не везде пригодный.
2 окт 18, 16:41    [21692972]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
vitkhv
Member

Откуда: Москва
Сообщений: 940
Котовасия
Хочется императивности, вместо "селект ... фром ... вэрэ..." чтобы "for (int i = 1...,", как у пацанов из одинэс... ;)

У пацанов из 1С ужо 15 лет как селект ....фром.....вэрэ, только там ВЫБРАТЬ.....ИЗ.....ГДЕ.
Пацаны из 1С в части SQL ужо давно тебя уделают, пока ты думаешь что ты крут в SQL со своими PIVOT\UNPIVOT, CTE и прочей магией, пацаны из 1С на чистом и незамутненном SQL решают задачи практически любого уровня сложности.
2 окт 18, 18:25    [21693113]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Котовасия
Хочется императивности, вместо "селект ... фром ... вэрэ..." чтобы "for (int i = 1...,", как у пацанов из одинэс... ;)


Tak?

declare @tbl TABLE (id int not null identity primary key, value float)
insert into @tbl (value)  values (2); 
insert into @tbl (value)  values (5); 
insert into @tbl (value)  values (1); 


WITH cte AS ( SELECT 1 AS i, value FROM @tbl where id = 1 UNION ALL SELECT i = i + 1, t.value FROM cte JOIN @tbl t ON t.id=cte.i+1 )
    SELECT * FROM cte
2 окт 18, 21:55    [21693411]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
Пацаны из 1С в части SQL ужо давно тебя уделают


Ну вот, пришел пацан из 1С :)
2 окт 18, 22:41    [21693490]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53041
Я практически ничего не понял из фразы где там 1С-ники что-то решают и решают эффективно.
Хотел-бы посмотреть. Реально хотел. Где тут 1С-ники. Ану покажите мне так вот чтоб я прямо восхитился!
2 окт 18, 22:49    [21693498]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
Насчет 1с ясно одно - там sql не ненавидят.
2 окт 18, 23:15    [21693519]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
H5N1, короче, вы только роботов по одному шаблону обучаете или еще что то делаете?
2 окт 18, 23:17    [21693520]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
Ivan Durak
это от бедности. Ну нельзя же всерьез считать что экспорт из БД террабайта в текстовый файл а потом его обработка питоном - это эффективнее чем обработка внутри бд.

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

Ivan Durak
плохо работает там где нету связанных данных. Как только данные появляются связанные, разные сущности с FK и т.п. сразу же SQL оказывается эффективен

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

Eugene New
Так абсолютно все или какой-нибудь? Проведите границу применимости своего метода. Ну там для обучения нейронных сетей или еще чего то, неспособного использовать sql-запросы. Потому что вы говорите так, что создается ложное ощущение универсальности вашего подхода.


потому что знаю как работают Ынтерпрайзы с данными. самый популярный тул - sas data miner, там аналитик занимается кластеризацией, тренировкой моделей и прочим. все данные тянет из субд.
в последнее время более модное направление анализировать R иди питоном. берут какую-нить модную ML либу, типа tensorflow, у которой есть обертки для R/питона и тянут данные прочь из субд.
самое близкое к субд видел примерчики у майкрософт, они предлагают питон скрипты в субд запускать. но это тоже лишь иллюзия, реально там точно так же данные из движка субд копируются в питон.

Eugene New
H5N1, короче, вы только роботов по одному шаблону обучаете или еще что то делаете?

что то еще делаем. например теперь вместо оракла считаем всякие KPI метрики, которые вроде как отлично ложились на SQL. но оракл был на старом железе, требовал апгрейда, апгрейд это лицензии и сумасшедшие суммы. теперь и эти задачи с оракла ушли и никакие индексы, транзакции и консистентные наборы не спасли.
3 окт 18, 08:19    [21693639]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
mayton
Хадуп и Оракл это разные классы систем. Их use-cases пересекаются очень в малом множестве.
И если вы нашли применение Хадуп-у - то это круть. И вы - хороший архитектор по данным.
Но Хадуп не может заменить Оракл на обработке оперативных данных.

пересекаются уже на достаточном множестве. ETL, DWH, аналитика это уже огромный пласт. по оперативным данным тоже уже начинает отгрызать. сейчас на хадупе модная тема real time + streaming приложения. те самые оперативные данные. да, там поток не в смысле финансовых транзакций пока, но ужас то в том что там это пипец как развивается, а рсубд по сути в коме.
ну и мое мнение, что в плане олтп с ораклом будут бодаться in memory grids типа apache ignite. там заявлены acid транзакции и redo log, консистентность. при этом ignite уже скрестили со спарком и внедрить пытаются не волосатые хипстеры, а уже сбер. и снова цель заместить реляционный оракл.
кстати и в хадупе клоудера пилит kudu энжин с mvcc, с undo и redo логом, с консистентным чтением. "Хадуп не может заменить Оракл" - если кома рсубд затянется будет то же что в аналитике и DWH.
3 окт 18, 08:52    [21693659]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
H5N1,
как с надежностью данных на вашем халупе? Вроде там отказ от транзакций и целостности, не так ли?
И вообще кто-нибудь проверяет, что выходит в результате или довольны тем, что просто заработало-закрутилось?
Если проверка результатов есть, то какими методами?
3 окт 18, 09:10    [21693670]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
Eugene New
как с надежностью данных на вашем халупе? Вроде там отказ от транзакций и целостности, не так ли?

для задач DWH все там хорошо. в плане транзакций их снепшоты на уровне hdfs мне нравятся даже больше. в оракле при загрузки в DWH транзакции тоже не особо используются, крупные загрузки грузят в стейджинг таблицы и потом делают exchange partition. если же без exchange patrition то грузят с коммитами каждые мульон записей. в результате клиенты видят данные не столь уж консистенно.
в хадупе же есть такая штука как hdfs snapshot, новый батч грузится в новый снепшот, пока идет загрузка и перестройка витрин клиенты пускают sql видят данные старые данные. когда загрузка завершается, переключается снепшот. старые квери видят старый снепшот и заканчивают работу на старом, новые квери уже с новым снепшотом будут работать. по мне так это круче, учитывая что тут наверно можно чуть поработать руками и вообще переключение снапшотов всех таблиц почти в один момент времени устраивать.

Eugene New
И вообще кто-нибудь проверяет, что выходит в результате или довольны тем, что просто заработало-закрутилось?
Если проверка результатов есть, то какими методами?

ссылочной целостности нет, но и тут как бы кардинальных отличий с рсубд нет. в рсубд на больших данных точно так же ETL процессы валидируют данные по сути вручную, отбрасывают откровенно кривые данные и отключают foreign keys перед загрузкой. причем на сколько знаю там тоже религиозные воины идут, нужно ли включать fk после загрузки.
что касается проверок, то да, валидация входящих данных проходит. после поступления данных считается тучи счетчков, те же ML алгоритмы строят прогнозы. даже если технически все данные были валидны, но кривые в логике эти прогнозы начнут чушь выдавать, что не быстро, но тоже отлавливает баги.
3 окт 18, 10:12    [21693740]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
vitkhv
Member

Откуда: Москва
Сообщений: 940
mayton
Я практически ничего не понял из фразы где там 1С-ники что-то решают и решают эффективно.
Хотел-бы посмотреть. Реально хотел. Где тут 1С-ники. Ану покажите мне так вот чтоб я прямо восхитился!

А что хотел та, ну акромя общих фраз?
3 окт 18, 10:30    [21693757]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
vitkhv
Member

Откуда: Москва
Сообщений: 940
Eugene New
Насчет 1с ясно одно - там sql не ненавидят.

Это точно, любят.
А то смотрю тут сквозь губу к одинэсникам.
Решают задачи люди на SQL, разные задачи.
Возможно как пример https://infostart.ru/public/336783/
расчет хэшфункции в запросе, без всяких HASHBYTES.
3 окт 18, 10:41    [21693764]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Eugene New
Member

Откуда:
Сообщений: 456
H5N1,
может вопрос наивный, но как вообще можно судить о верности работы самообучающегося робота, алгоритма работы которого вы в принципе не знаете и не понимаете? и которому скармливаете огромные сырые массивы данных, собранных "абы как". То есть неизвестный алгоритм, на входе которого неизвестно что. Откуда уверенность, что на выходе будет что то правильное?

Понятно, что если деньги платят и что то такое крутое крутится и даже какой то результат показывает, то можно и не думать об этом. И никто особо не придерется, так как никто вообще не понимает, что там происходит. Некий черный ящик. "Дельфиский оракул".

Но ведь сейчас эти процессы распространяют на довольно таки важные для людей области.

Или и тут вовсю агиле принцип - все ок, пока никто не жалуется или жалобы не доходят?
3 окт 18, 10:56    [21693783]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
vitkhv
Member

Откуда: Москва
Сообщений: 940
Lepsik
Котовасия
Хочется императивности, вместо "селект ... фром ... вэрэ..." чтобы "for (int i = 1...,", как у пацанов из одинэс... ;)


Tak?

declare @tbl TABLE (id int not null identity primary key, value float)
insert into @tbl (value)  values (2); 
insert into @tbl (value)  values (5); 
insert into @tbl (value)  values (1); 


WITH cte AS ( SELECT 1 AS i, value FROM @tbl where id = 1 UNION ALL SELECT i = i + 1, t.value FROM cte JOIN @tbl t ON t.id=cte.i+1 )
    SELECT * FROM cte


Чего в 1С нет и очень сильно не хватает так это CTE.

Для задач разулования самое то.
Я CTE для 1С использую, но через ADO + VIEW на 1С таблицы,
чтобы не писать
SELECT _IDRref FROM _Reference167

а писать
SELECT Ссылка FROM [Справочник.Номенклатура]


Еще CTE использую для выборки по иерархии из 1С справочников.
Ну типа так:

;WITH hierarchy(Ссылка, Родитель) AS 

(
SELECT cls.Ссылка
         ,cls.Родитель
         FROM [Справочник.Номенклатура] cls WITH (NOLOCK)
WHERE Ссылка= @Родитель
UNION ALL
SELECT    t.Ссылка
         ,t.Родитель
         
FROM [Справочник.Номенклатура] t WITH (NOLOCK)
JOIN  hierarchy hry 
ON t.Родитель= hry.Ссылка
)
SELECT hry .Ссылка 
      ,hry .Родитель
   	 ,t.*
FROM hierarchy hry 
JOIN [Справочник.Номенклатура]  t  WITH (NOLOCK) on hry .Ссылка= t .Ссылка
3 окт 18, 11:00    [21693789]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить