Здравствуйте, Слава, Вы писали:
С>Да все у них ломается.
С>Повторюсь про Монгу — три с половиной панка решили за два года написать то, что превзойдет решения, разрабатываемые с конца 80х не самыми глупыми людьми. Если надо хранить документы Json — в постгресе это есть, и функциональные индексы по этим документам тоже возможны. Я сейчас с ходу не найду, был документ на slideshare, где меряли производительность постгреса и монги на одинаковой задаче хранения документов. Монга мало того, что проиграла по скорости, у нее еще и memory footprint заметно выше оказался.
1. JSON PostgreSQL появился не так давно.
2. Главное преимущество баз типа MongoDB вовсе не в JSON, а в поддержке шардинга из коробки и удобными инструментами работы с этим (знаменитые map/reduce и т.п.). У SQL БД с этим всё очень печально.
3. Зачем искать какой-то сомнительный документ на slideshare, когда мы несколько лет назад прямо на этом форуме проводили тесты. И SQL тогда помнится очень заметно слил MongoDB. )))
С>За реляционками стоит математика и десятилетия исследований, опыта разработчиков и база уже написанного кода. За NoSQL — желание сделать подгружаемую ленту, "как в твиттере", больше там ничего нет. Еще "мы хотим хранить данные без структуры, потому что сегодня мы пишем приложение для продажи какутсов, а когда инвестор не повелся — быстренько его переделаем под продажу роз, а что — и у тех, и у тех есть колючки". NoSQL в вебе — это социальное явление, для перепродажи говностартапов, которые годятся только для перепродажи, использовать и монетизировать их нельзя.
Хыхы, так и запишем, что Cassandra, HBase, BigTable и т.п. — это всё детский игры без малейшей математики))) А всякие там гуглы с фейсбуками — это говностартапы. )))
НС>>>Кто то из них не поддерживает стандарт? Уж SELECT OVER то все должны уметь. M>>MySQL вестимо.
НС>Ты этого уродца с нормальными серверами не ровняй.
Еще один нашелся. Какая разница, уродец он или не уродец. Это один из самых популярных в мире движков. Особенно в контексте веб-разработки, о которой тут вещал alex_public.
Здравствуйте, Mamut, Вы писали:
_>>Ты так пишешь, как будто бы я привёл какое-то исключение. В то время как подобный расклад является как раз нормой в мире веб-движков.)
M>Ага. Ты еще наугад применяешь слово «веб-движок».
Вообще то не наугад))) Я его использую вполне каноническим способом — для всех этих бесконечных форумов, блогов, чатов, галерей, магазинов, CMS и т.п. готовых систем. Которые достаточно инсталлировать (вместе с http сервером и какой-то СУБД), настроить и получить готовое работающее приложение.
M>Я не знаю, что ты называешь «движком» и «легким слоем абстракции», так что эти вопросы к тебе.
Про движок написано выше. А тонкий слой абстракции — это очевидно просто часть кода в этом движке.
_>>Ну так я вообще то как раз на протяжение всей этой темы и пишу, что оптимального обобщённого решения не существует. M>
M>вызовет привязку к конкретной БД как раз только в случае отсутствия слоя абстракции БД. А в нормальных местах работа идёт именно через него + имеем набор реализаций этого слоя под каждую конкретную БД
M>Внезапно мифический слой абстракции превратился в «я на протяжение темы говорю, что обобщенного решения не сущесвтует», ага
Ты как-то странно читаешь. Слой абстракции легко реализуется (можно полюбоваться на него в большинстве движков), но для конкретного движка. Если же мы попытаемся сделать универсальное решение, то сделать его таким же удобным и эффективным не получится. Но кое-что выйдет — получится просто некая ORM. Но я уже тут писал, что как раз не сторонник ORM из-за описанных выше проблем.
M>Итак. Любые мифические «движки», которые так охрененно все абстрагируют, делают ровно две вещи: M>- реализуют только общий для поддерживаемых баз данных функционал M>- реализуют некоторое количество неоптимальных хаков для эмуляции некоторых вещей, которые есть в одной базе, но нет в другой.
Ну так этого общего функционала (как минимум стандарта SQL) вообще то обычно вполне достаточно для данных целей.
M>В итоге все эти мегакрутые phpbb вместо того, чтобы делать один-три запроса к базе на страницу, делают по нескольку десятков.
Это ты сам проверял? )
M>В итоге в мегасупер мифических системах, работающих со всеми базами, появляются неисправляемые детские баги, произрастающие именно из-за того, что поддерживается только общая функциональность + хаки. (Я лично видел «движок», который, например, эмулировал транзакции для MySQL).
В этой среде вообще процветает php и говнокод. Но это разве имеет какое-то отношение к нашей дискуссии? )
M>В итоге любое приложение, которому важна хоть какая-нибудь производительность, момнетально скатывается в заточенные под конкретную базу данных запросы, и никакого «ах-ах-ах тонкий слой абстракции, работающий со всем базами» в них не существует.
Если принять твоё утверждение на веру, то тогда остаётся только предположить, что всем начхать на производительность (правда при этом подобные спокойно форумы держат огромные нагрузки, ну да ладно), т.к. работа с разными БД встроена в большинство из них.
M>Ты же продолжаешь активно игнорировать те факты из реальности, о которых я говорю: три топовые базы данных. Oracle, MySQL, MSSQL. M>- В MySQL нет windowing functions и hierarchical queries. Да и транзакции там через жопу. Плюс еще до недавнего времени запрос должен был расставлять индексированные поля в начале запроса, иначе можно было получить full table scan на все таблицы в запросе на ровном месте
Так я вроде как ясно писал, что пересечения функциональности вполне хватает. Что касается транзакций, очерёдности полей и т.п, то как раз для такого слой абстракции и является идеальной вещью. Что бы не отслеживать подобное по всему коду приложения.
M>- В Oracle hierarchical queries еще до недавнего времени реализовались через CONNECT BY и никакой «тонкий слой абстракции» не переписал бы хоть сколько-нибудь сложный запрос под CTE для MSSQL
Вот уж CTE от MS — это точно не то, ради чего стоит нарушать переносимость. )))
M>- это мы еще не говорим про иногда несовместимые типы данных в базах (а иногда совместимые, но с разной семантикой и т.п.) M>- это мы еще не говорим про то, что часто запросы надо оптимизировать под конкретные оптимизаторы конкретных баз (что никакой «тонкий слой абстракции» не сделает никогда)
И опять же запирание таких вещей в компактной области (а не растаскивание по всему приложению) является наиболее верным архитектурным решением. Даже если не планировать поддержку многих СУБД. Хотя при такой архитектуре добавление поддержки иной СУБД делается очень легко.
_>Ну так этого общего функционала (как минимум стандарта SQL) вообще то обычно вполне достаточно для данных целей.
Каких «данных»? Сделать три десятка запросов вместо трех? Да, безусловно хватает
M>>В итоге все эти мегакрутые phpbb вместо того, чтобы делать один-три запроса к базе на страницу, делают по нескольку десятков. _>Это ты сам проверял? )
Вообще-то, да
M>>В итоге в мегасупер мифических системах, работающих со всеми базами, появляются неисправляемые детские баги, произрастающие именно из-за того, что поддерживается только общая функциональность + хаки. (Я лично видел «движок», который, например, эмулировал транзакции для MySQL).
_>В этой среде вообще процветает php и говнокод. Но это разве имеет какое-то отношение к нашей дискуссии? )
Прямое. По ссылке — как раз описание того, что происходит в этих мегакрутых мифических движках, для которых «хватает стандарта SQL».
M>>В итоге любое приложение, которому важна хоть какая-нибудь производительность, момнетально скатывается в заточенные под конкретную базу данных запросы, и никакого «ах-ах-ах тонкий слой абстракции, работающий со всем базами» в них не существует.
_>Если принять твоё утверждение на веру, то тогда остаётся только предположить, что всем начхать на производительность (правда при этом подобные спокойно форумы держат огромные нагрузки, ну да ладно), т.к. работа с разными БД встроена в большинство из них.
Они «держат огромные нагрузки» только в воспаленном воображении истово верующих в магические слои абстракции. На практике это выливается в дичайщую головную боль для мейнтенеров, с переписыванием и выкидыванием кусков кода, с попытками понять, почему при тысяче посещений в сутки половина страниц открывается с пятисекундной задержкой на нехилом железе, анализом сгенеренных этими чедо-слоями запросов и т.п.
_>Так я вроде как ясно писал, что пересечения функциональности вполне хватает. Что касается транзакций, очерёдности полей и т.п, то как раз для такого слой абстракции и является идеальной вещью. Что бы не отслеживать подобное по всему коду приложения.
Действительно. Ведь «движок абстракций» знает, где и какие у нас индексы в базе, ага. И еще он знает, как эмулировать транакции правильно, ага, для баз с плохой поддержкой транзакций. Ах, да, я забыл. Это же магический движок.
M>>- В Oracle hierarchical queries еще до недавнего времени реализовались через CONNECT BY и никакой «тонкий слой абстракции» не переписал бы хоть сколько-нибудь сложный запрос под CTE для MSSQL _>Вот уж CTE от MS — это точно не то, ради чего стоит нарушать переносимость. )))
Это не тебе решать, а тем, кто пишут приложение.
В общем, ты продолжаешь отвечать не на то, что тебе пишут, а на собственное представление о том, что тебе пишут.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не надо за меня додумывать. У линка, как и у любой технологии, есть свои особенности. И с графами все очень зависит от этих графов. Конкретно в случае БД есть много разных способов эти графы представлять. Например для иерархии есть штук 10 вариантов. НС>И проблема с графами вовсе не у линка, а у самих РСУБД. Линк как раз с графами спокойно работает, см. тот же XLinq.
Нуу это если воспринимать linq только как IEnumerable + деревья выражений, т.е. без "sql" команд.
НС>Классы в шарпе выделяются в куче отдельно, структуры (и инт как частный случай) — по месту.
Про это я в курсе. ))) Я тебя не правильно понял по поводу их отображения из sql. )
НС>Динамика это совсем не то, хоть и выглядеть в первом приближении может похоже. Там, к примеру, нет проблемы с нарушением инвариантов, потому что это нарущение в динамике возможно даже для метаданных и подобная забота будет сродни сбиванию соринок с сапог посреди размокшего поля.
Да, для любителя статически типизированных языков там кажется всё печально. Но тем не менее оно вполне себе работает. Более того, большая часть веб как раз так и живёт. )))
_>>А если есть возможность реализовать подобное без потери производительности? НС>Нет такой возможности. Не умеет РСУБД хранить объектный граф эффективно.
В произвольном случае конечно. Однако для конкретной задачи (особенно если в ней нет произвольных деревьев) это становится более реально.
_>>Функция GetUser очевидно возвращает все поля пользователя. НС>Ну и все, можно забыть про перформанс тогда.
С чего бы это? )
_>> Если же нам надо получить отдельный столбец, то для этого естественно другая функция будет. НС>Возвращать она какой тип будет? А если нужно отдельные 5 столбцов?
Да какой угодно. Хоть итератор по кортежу. Без уточнения конкретной задачи это всё бессмысленный разговор.
_>>Работа с хранилищем в терминах приложения, а не в терминах устройства хранилища. НС>Это не критерий, это следствие. Вторая попытка.
Это не критерий и не следствие, а цель. А в случае её достижения мы получаем набор бонусов:
— родное (через свои типы) API к хранилищу
— программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему
— при необходимости можно легко сменить тип хранилища.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Там вообще почти всегда динамические языки, так что всякие разновидности ORM рисуются влёт. НС>Посмотрел пример RoR — http://www.tutorialspoint.com/ruby-on-rails/ НС>Нигде никаких лишних слоев, обращение и из контроллеров и даже из вьюх напрямую к объектам ORM.
RoR так же как и Django являются фреймворками для написания приложений, а не готовыми движками. Соответственно там нет набора чёткое определённых запросов и соответственно невозможно построить подобный слой абстракции. Возможно только использовать вместо него некую ORM (так сказать лайт вариант), что у них и сделано. Кстати, а про ORM я тут уже как раз писал, что это попытка обобщения подобного слоя абстракции. И хотя в ней частично теряется удобство и иногда быстродействие, но абстрагирование от конкретной СУБД вполне сохраняется.
Здравствуйте, AndrewVK, Вы писали:
AVK>Как очередной *bb научится иерархические форумы, так сразу и приходите. А ленту показывать много ума не нужно.
Что подразумевается под иерархическим форумом? ) Если речь про древовидное отображение ветки дискуссии, то это в очень многих имеется (причём в виде переключателя).
_>> и отзывчивость повыше. AVK>Отзывчивость rsdn.ru в производительность сервера сейчас почти нигде не упирается.
Хм, а во что тогда упирается? Потому как у меня периодически при отправке сообщения на форум сайт подвисает, держится так какое-то время и потом выдаёт какую-то странную ошибку. Причём повторная отправка (хорошо хоть браузер сохраняет текст сообщения при возврате на предыдущую страницу) обычно проходит нормально.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Пока мой комментарий из этих цифр: для быстрых sql запросов смысл снижать накладные расходы за счёт linq всё же есть. НС>С быстрыми sql запросами обычно и проблем с перфомансом нет.
Однако если такие запросы наиболее популярны, то оптимизация подобных накладных расходов может позволить держать на том же сервере гораздо большую нагрузку.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> Всё же ты не в реальном мире живёшь. ) Одно IT подразделение Сбербанка больше 3000 человек НС>И сколько из них программисты?
Ну так я и для mail.ru брал общую численность сотрудников, так что всё честно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И не только постгри. mssql в следующем релизе тоже что то похожее обещает. Только что тебя удивляет здесь — непонятно. Появился спрос — производители реагируют.
Не удивляет, а радует. ) Правда пока это всё дико несовместимо между собой, так что подходит для использования только в проектах заточенных на одну БД.
Здравствуйте, Mamut, Вы писали:
_>>Ну так этого общего функционала (как минимум стандарта SQL) вообще то обычно вполне достаточно для данных целей. M>Каких «данных»? Сделать три десятка запросов вместо трех? Да, безусловно хватает
Пока что это твоё голословное утверждение.
_>>Это ты сам проверял? ) M>Вообще-то, да
Т.е. ты хочешь сказать, что копался в коде phpbb, нашёл там десятки запросов к БД на страницу и при этом знаешь как сократить это число до 1-3. Правильно? )
M>Они «держат огромные нагрузки» только в воспаленном воображении истово верующих в магические слои абстракции. На практике это выливается в дичайщую головную боль для мейнтенеров, с переписыванием и выкидыванием кусков кода, с попытками понять, почему при тысяче посещений в сутки половина страниц открывается с пятисекундной задержкой на нехилом железе, анализом сгенеренных этими чедо-слоями запросов и т.п.
Хыхыхы, тысяча посещений в сутки? ))) У меня помнится ещё лет 10 назад оно держало на шаред-хостинге (сайт с форумом для хобби сообщества некого обустраивал) десятки тысяч. Что уж тут говорить о нормальном современном сервере. Причём я тогда не написал ни строчки когда.
M>Действительно. Ведь «движок абстракций» знает, где и какие у нас индексы в базе, ага. И еще он знает, как эмулировать транакции правильно, ага, для баз с плохой поддержкой транзакций. Ах, да, я забыл. Это же магический движок.
Какой ещё "движок абстракций"? Я про такое нигде и никогда не писал. Снова твои фантазии. ))) Если же мы говорим о слое абстракции в конкретном приложение, то он действительно знает всё и про индексы в данной БД и про всё остальное.
Здравствуйте, alex_public, Вы писали:
Н>>Так я что-то не понял, по твоему эти твои ссылки подтверждают моё утверждение, опровергают его или что? ) Как они вообще к нему относятся? )
Первое -- это о том как "работает" "шардинг из коробки". Второе -- это о том как "работает" MongoDB вообще.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Mamut, Вы писали:
M>Еще один нашелся. Какая разница, уродец он или не уродец.
Большая. Потому что если для нормальных SQL серверов еще есть шанс более менее сносный результат, работающих на нескольких серверах получить, то с MySql — никаких.
Здравствуйте, alex_public, Вы писали:
_>Однако если такие запросы наиболее популярны, то оптимизация подобных накладных расходов может позволить держать на том же сервере гораздо большую нагрузку.
Здравствуйте, alex_public, Вы писали:
_>Нуу это если воспринимать linq только как IEnumerable + деревья выражений, т.е. без "sql" команд.
Что такое "sql" команды и почему у них проблемы с графами?
_>Да, для любителя статически типизированных языков там кажется всё печально. Но тем не менее оно вполне себе работает.
Это неважно. Важно что линк, основная задача которого подружить системы типов БД и CLR, в контексте динамических языков абсолютно нерелевантен.
_>>>А если есть возможность реализовать подобное без потери производительности? НС>>Нет такой возможности. Не умеет РСУБД хранить объектный граф эффективно. _>В произвольном случае конечно. Однако для конкретной задачи (особенно если в ней нет произвольных деревьев) это становится более реально.
Ну а для конкретного случая и у линка проблем нет.
_>>>Функция GetUser очевидно возвращает все поля пользователя. НС>>Ну и все, можно забыть про перформанс тогда. _>С чего бы это? )
С того что лишние поля будут выбираться без надобности.
_>>> Если же нам надо получить отдельный столбец, то для этого естественно другая функция будет. НС>>Возвращать она какой тип будет? А если нужно отдельные 5 столбцов? _>Да какой угодно.
Какой?
_> Хоть итератор по кортежу.
Во во. По кортежу.
_> Без уточнения конкретной задачи это всё бессмысленный разговор.
Тут все вполне конкретно. В реальных задачах набор полей в основном уникален. Рисовать на каждый случай новый тип — геморой, возвращать недозаполненный тип или безликий кортеж — отличный способ прострелить себе ногу, возвращать все поля — удар по перформансу.
_>>>Работа с хранилищем в терминах приложения, а не в терминах устройства хранилища. НС>>Это не критерий, это следствие. Вторая попытка.
_>Это не критерий и не следствие, а цель.
На цель, извини, не тянет. Цель любого продуктва — удовлетворять требованиям. Заказчик такого требования не выставляет. Так что это уже твои экзерсисы. Поэтому попробуй их обосновать, а не выдавай за аксиому.
_> А в случае её достижения мы получаем набор бонусов: _>- родное (через свои типы) API к хранилищу
Что такое "родное API" и чем оно лучше неродного?
_>- программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему
IQueryable обеспечивает тоже самое.
_>- при необходимости можно легко сменить тип хранилища.
Всё же ты не в реальном мире живёшь. ) Одно IT подразделение Сбербанка больше 3000 человек
