Комментарии 201
Сразу оговорюсь — я не имею ничего против размещения части бизнес логики в хранимых функциях, если это предусмотрено в архитектуре системы и оправдано по ряду практических соображений, которые выходят за рамки этой статьи.когда вы наконец поймёте что «размещения части бизнес логики в хранимых функциях» это калька с подхода на императивных языках типа Java и C++.
В реляционных базах данных сама структура таблиц уже является описанием бизнес-логики.
В реляционных базах данных сама структура таблиц уже является описанием бизнес-логики.
О_о
Структура таблиц описывает только способ хранения данных. А бизнес-логика — это условия, ветвления, переходы, которые позволяют реализовать процесс, не описать.
ну, судя по минусам это действительно слишком сложно для большинства.
Есть целый пласт языков в которых нет ветвления и переходов вообще. Это модные сейчас функциональные языки программирования, например.
Структура таблиц и связей в реляционных базах является описанием самих данных а также способом работы с ними.
Простейший пример:
таблица Отделы и таблица Сотрудники имеющая ссылку на отдел. Такая структура однозначно описывает бизнес-правило «каждый сотрудник должен принадлежать какому-то отделу». Причём SQL-сервер будет отслеживать эту связь и никаким способом, ни на каком языке программирования не удастся засунуть в базу данные нарушающие это правило.
Ну и т.д.
Есть целый пласт языков в которых нет ветвления и переходов вообще. Это модные сейчас функциональные языки программирования, например.
Структура таблиц и связей в реляционных базах является описанием самих данных а также способом работы с ними.
Простейший пример:
таблица Отделы и таблица Сотрудники имеющая ссылку на отдел. Такая структура однозначно описывает бизнес-правило «каждый сотрудник должен принадлежать какому-то отделу». Причём SQL-сервер будет отслеживать эту связь и никаким способом, ни на каком языке программирования не удастся засунуть в базу данные нарушающие это правило.
Ну и т.д.
Бизнес-логика не должна быть завязана на способ хранения.
Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL, и в один прекрасный момент, полностью перейти либо на первое, либо на второе.
В реализации бизнес-логики, я не смотрю в сторону БД, а оперирую свойствами объектов.
Если у вас в сознании частью бизнес-логики является система хранения данных, то у меня для вас плохие новости, вы не понимаете, что такое абстрагирование.
Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL, и в один прекрасный момент, полностью перейти либо на первое, либо на второе.
В реализации бизнес-логики, я не смотрю в сторону БД, а оперирую свойствами объектов.
Если у вас в сознании частью бизнес-логики является система хранения данных, то у меня для вас плохие новости, вы не понимаете, что такое абстрагирование.
>Бизнес-логика не должна быть завязана на способ хранения.
>Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL
Даже если держат данные в нескольких oracle БД — это уже гарантия поиметь массу неприятностей из-за распределенности.
Есть такая штука — ACID-тест для БД. Если Вы собираетесь хранить данные в нескольких БД, то о целостности данных можно смело забыть!
>Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL
Даже если держат данные в нескольких oracle БД — это уже гарантия поиметь массу неприятностей из-за распределенности.
Есть такая штука — ACID-тест для БД. Если Вы собираетесь хранить данные в нескольких БД, то о целостности данных можно смело забыть!
В том случае, если целостность необходима на уровне БД.
В противном случае можно потратиться на уровень абстрагирования, решающий инциденты с расхождением целостности и получить масштабируемость.
Впрочем, любая масштабируемость — это уже дорого )
В противном случае можно потратиться на уровень абстрагирования, решающий инциденты с расхождением целостности и получить масштабируемость.
Впрочем, любая масштабируемость — это уже дорого )
Для одинаковых данных верно. Для слабосвязанных — нет. Например, логи работы могут всегда лежать отдельно, но использоваться для формирования общих отчетов.
ACID ничто иное как илюзия. CAP теорема работает даже для одного узла. В любом компъютере есть процессор, память, кеши разные, постоянная память. И пусть доступность или согласованость теряется на меньшие кванты времени чем при распределенной системе, но потери есть. А теперь усложним задачу. Скажите хорошему банку что базу хранить будем в одном экземпляре и в одной локации. Банк не пройдет судить, а вас отправят в сад. Добавляем второй узел и об ACID забываем. Amazon как-то столько лет живет без ACID?
ACID для БД не иллюзия. Наборот, БД без ACID — это не БД :)
Суть в том, что невозможно увидеть эту рассогласованость. Максимум, что может быть — потеря незакомиченных транзакций.
Разные локации используются не только для распределения нагрузки, а в основном для резервирования, что организуется за счет возможностей репликации на уровне дисковых массивов или возможностей репликации самой БД, что обеспечивает опять же целостность за исключением незакомиченных транзакций.
Про амазон ничего не скажу, не в курсе их архитектуры — я 14 лет oracle dba больших БД.
Суть в том, что невозможно увидеть эту рассогласованость. Максимум, что может быть — потеря незакомиченных транзакций.
Разные локации используются не только для распределения нагрузки, а в основном для резервирования, что организуется за счет возможностей репликации на уровне дисковых массивов или возможностей репликации самой БД, что обеспечивает опять же целостность за исключением незакомиченных транзакций.
Про амазон ничего не скажу, не в курсе их архитектуры — я 14 лет oracle dba больших БД.
Если вы не видите рассогласованости это не значит что ее нет. Вы просто теряете в доступности и уже есть множество приложений где эти потери недопустимы и 100-мс это непозволительно долго. Amazon Dynamo DB позволяет милисекундные задержки. Не знаю как в Оракле но вчера проскакивала статья о T -SQL и специальной опции no lock которая позволяет увидеть рассогласованость, но увеличить доступность.
Теореме CAP уже более 10 лет и пока не нашлось способных ее опровергнуть. Из 3-х свойств одновременно возможны только 2.
14-лет большой срок, за это время успели сменился 2-3 технологические эры, стоит расширять свой кругозор.
Теореме CAP уже более 10 лет и пока не нашлось способных ее опровергнуть. Из 3-х свойств одновременно возможны только 2.
14-лет большой срок, за это время успели сменился 2-3 технологические эры, стоит расширять свой кругозор.
а при чем в данном разрезе целостность?
мы про бизнес-логику говорим. А уж для чего понадобилось разделять данные по различным БД это дело десятое.
мы про бизнес-логику говорим. А уж для чего понадобилось разделять данные по различным БД это дело десятое.
Например, бизнес логика — вставить запись в таблицу платежей (insert) и обновить баланс клиента (update), зафиксировать изменения (commit).
Теперь поясните, если таблицы платежей и балансы лежат в разных БД — как Вы сможете гарантировать, во-первых, что не окажется зафиксирован только insert или только update в случае сбоев, во-вторых, при нормальной работе другие процессы, читающие данные по этому клиенту не получат расхождение в данных платежей и баланса по клиенту?
Теперь поясните, если таблицы платежей и балансы лежат в разных БД — как Вы сможете гарантировать, во-первых, что не окажется зафиксирован только insert или только update в случае сбоев, во-вторых, при нормальной работе другие процессы, читающие данные по этому клиенту не получат расхождение в данных платежей и баланса по клиенту?
вы не поняли.
зачем в данном ключе вообще разговаривать о целостности?
с тем же успехом мы сейчас можем начать говорить о погоде, но при чем тут погода?!
я же говорю о том, что бизнес-логика это совершенно другой уровень абстракции.
зачем в данном ключе вообще разговаривать о целостности?
с тем же успехом мы сейчас можем начать говорить о погоде, но при чем тут погода?!
я же говорю о том, что бизнес-логика это совершенно другой уровень абстракции.
А бизнес логика при том, что она должна быть обеспечена некими механизмами, которые гарантировано работают.
Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя :)
Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя :)
При чем способы хранения данных к бизнес-логике? Я могу хранить платежи и балансы как угодно, и это никак не повлияет на бизнес-логику.
Хорошо. Например Вы — банк, у Вас есть входящий баланс счета на дату, проводки по нему и исходящий баланс. То, что появление новой проводки изменяет баланс — это бизнес-логика или нет?
бизнес-логика
Вот, хорошо. Так речь о том, что если проводки и баланс лежат в разных БД, то вы не сможете обеспечить между ними соотвествие — может пропасть одно из двух полностью, либо в выписке по счету в определенный момент времени у вас не сойдется начальный баланс, сумму по проводкам и конечный баланс.
Не знаю, как еще доступнее объяснить :)
Не знаю, как еще доступнее объяснить :)
Вы смотрите на БД как на неотъемлемую часть процесса бизнес-логики. Я смотрю на БД как на поставщика данных. Не более того.
Я Вам объяснил, почему БД является неотъемлимой частью.
Почему вы не можете абстрагироваться от метода хранения данных?
Нам не важно как хранятся наши данные.
В БД они, в файлах или в облаке.
Для бизнес-логики это не важно. При её проектировании мы оперируем сущностями. А как сущности хранят данные — это уже не важно при проектировке. За это отвечает ORM.
Нам не важно как хранятся наши данные.
В БД они, в файлах или в облаке.
Для бизнес-логики это не важно. При её проектировании мы оперируем сущностями. А как сущности хранят данные — это уже не важно при проектировке. За это отвечает ORM.
Советую ознакомится вот с этим, что бы понять что такое абстракция.
Ваша абстракция не проходит проверку ACID
Следовательно даже если она ничего не нарушает, в критических приложениях применяться не может.
Вы все еще хотите абсолютно абстрагироваться от метода хранения данных?
Следовательно даже если она ничего не нарушает, в критических приложениях применяться не может.
Вы все еще хотите абсолютно абстрагироваться от метода хранения данных?
>Ваша абстракция не проходит проверку ACID
Что за бред вы несете?
Что за бред вы несете?
Да не бредовее вашего:
«и в один прекрасный момент, полностью перейти либо на первое, либо на второе.»
Как только поработаете с чем-то сложнее сайта-визитки или что вы там делаете?
Так сразу и поймете насколько платформозависимы конкретные решения в более менее сложных системах и как проблематично найти тот самый «прекрасный момент», когда вы сможете позволить себе все поменять.
«и в один прекрасный момент, полностью перейти либо на первое, либо на второе.»
Как только поработаете с чем-то сложнее сайта-визитки или что вы там делаете?
Так сразу и поймете насколько платформозависимы конкретные решения в более менее сложных системах и как проблематично найти тот самый «прекрасный момент», когда вы сможете позволить себе все поменять.
серьёзно?
хм, а с чего вы взяли, что я не работал с проектами сложнее сайта-визитки? -))
хм, а с чего вы взяли, что я не работал с проектами сложнее сайта-визитки? -))
А я там же сразу и написал с чего я взял.
Ну, что я могу сказать вам. Судя по всему, вы работали в проекте(-ах) в которых была не достаточно хорошо продумана архитектура.
А все потому, что разрабатывали именно с точки зрения, что БД это часть бизнес-логики.
Одна из крупнейших ошибок при разработке.
Одна из крупнейших ошибок при разработке.
Это не ошибка. Эта логика проповедовалась на протяжении не одного десятка лет. В ней есть свой смысл и свои позитивные стороны. Но, как всегда, люди начали применять не тот инструмент не там.
Вы просто очень мало работали.
Независимо от качества продуманности архитектуры, логика зависит от того какие данные.
Поэтому полностью абстрагироваться от источника данных невозможно где-то кроме песочницы.
Но кому нужна песочница с хорошо продуманной архитектурой?
P.S. Чтобы уж совсем ясно было.
Действительным прорывом была машина тьюринга. А дальше с разной успешностью люди пытались от нее отойти.
К примеру, посмотрите на jvm. Созданная якобы для переносимости, но 32бит приложение java не может работать в 64бит JRE.
Независимо от качества продуманности архитектуры, логика зависит от того какие данные.
Поэтому полностью абстрагироваться от источника данных невозможно где-то кроме песочницы.
Но кому нужна песочница с хорошо продуманной архитектурой?
P.S. Чтобы уж совсем ясно было.
Действительным прорывом была машина тьюринга. А дальше с разной успешностью люди пытались от нее отойти.
К примеру, посмотрите на jvm. Созданная якобы для переносимости, но 32бит приложение java не может работать в 64бит JRE.
Извините конечно, но меня забавляют фразы про мой опыт и длительность работы в сфере разработки. Вы же обо мне ничего не знаете :)
Я ведь тоже могу заявить, что то в этом духе, однако не позволяю себе этого, т.к. это не конструктивно и не аргументированно.
Могу лишь спросить вас(для того что бы составить мнение о ваших знаниях), что значит абстракция и какой процесс на ваш взгляд, при разработке наиболее важен: синтез или декомпозиция?
Я ведь тоже могу заявить, что то в этом духе, однако не позволяю себе этого, т.к. это не конструктивно и не аргументированно.
Могу лишь спросить вас(для того что бы составить мнение о ваших знаниях), что значит абстракция и какой процесс на ваш взгляд, при разработке наиболее важен: синтез или декомпозиция?
К примеру, посмотрите на jvm. Созданная якобы для переносимости, но 32бит приложение java не может работать в 64бит JRE.
Вы это сейчас серьезно? Все прекрасно работает, я вам скажу даже больше свободно переносится не только между x86 и x86-64, но и на другие архитектуры, например SPARC, zSeries и т.д.
Что-то я даже засомневался…
Ан нет…
Одна из IDE отказалась запускаться на этом JRE
java version «1.7.0_05»
Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
А на этом заработало
java version «1.6.0_31»
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode)
Ну, а это вообще феерично.
gyazo.com/1cfbda5ea0978de80b211cee68b1fd0b
Верно?
Ан нет…
Одна из IDE отказалась запускаться на этом JRE
java version «1.7.0_05»
Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
А на этом заработало
java version «1.6.0_31»
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode)
Ну, а это вообще феерично.
gyazo.com/1cfbda5ea0978de80b211cee68b1fd0b
Верно?
Да Вы конкретней, не стесняйтесь сказать какая IDE и т.д., ни разу не сталкивался с подобной проблемой. Может быть какие пруфлинки найдутся, обсуждения на stackoverflow?
Что фееричного на скриншоте тоже совсем непонятно, Вы бы хоть удосужились пояснить.
Что фееричного на скриншоте тоже совсем непонятно, Вы бы хоть удосужились пояснить.
IDE? Да можете проверить на Eclipse, Netbeans, Idea.
И ниже все правильно и корректно расписали, именно из-за расширения gui и есть проблемы.
Про фееричность на скриншоте…
Там же желтым выделено. Вы прочитать не удосужились?
И прямым текстом сообщают, что если используется и 32 и 64 бит приложение, то вам «нужно» поставить и 32 и 64 бит JRE чтобы ваш ява-плагин работал в обоих случаях.
Кроссплатформенность во весь рост…
И ниже все правильно и корректно расписали, именно из-за расширения gui и есть проблемы.
Про фееричность на скриншоте…
Там же желтым выделено. Вы прочитать не удосужились?
И прямым текстом сообщают, что если используется и 32 и 64 бит приложение, то вам «нужно» поставить и 32 и 64 бит JRE чтобы ваш ява-плагин работал в обоих случаях.
Кроссплатформенность во весь рост…
Ну то что IDE не запускается еще не означает что дело в java-машине. Все эти IDE как правило используют native — расширения, вместо swing или awt в них используют swt, а это не чистая java.
Тот же eclipse 32 разрядный не заработает на 64 разрядной jvm, а все потому, что данная IDE включает в себя около 50 dll (windows версия), скомпилированных либо под 32 разряда, либо под 64. Разрядность этих библиотек должна соответствовать разрядности jvm.
Но вот любая программа, использующая исключительно jdk, будет работать как на 32 так и на 64 разрядной jvm независимо от того, на какой из них она скомпилирована
Тот же eclipse 32 разрядный не заработает на 64 разрядной jvm, а все потому, что данная IDE включает в себя около 50 dll (windows версия), скомпилированных либо под 32 разряда, либо под 64. Разрядность этих библиотек должна соответствовать разрядности jvm.
Но вот любая программа, использующая исключительно jdk, будет работать как на 32 так и на 64 разрядной jvm независимо от того, на какой из них она скомпилирована
Конечно же бизнес-логика. Я знаю к чему вы будете сейчас клонить, что если хранить в разных базах, то обновление одного параметра приведет к неконсистентности данных. На что я вам резонно возражу, что если все «кешировать» в промежуточном «оперативном» слое, то способ хранения этих данных перестает играть важную роль. Хранение есть хранение. Тенденция последних лет двадцати была такова, что все стремились переложить бизнес-логику на БД, хотя база — совершенно не подходящее место для этого. И были воспитаны поколения людей, которые мыслят подобным образом. Это не плохо, это один из путей развития, но он привел в тупик многие компании.
Вопрос, сможет ли этот промежуточный кэш пройти тот же ACID-тест?
Про тупик для многих компаний было бы интересно почитать.
Самые объемные и нагруженные БД, имхо, моибльных операторов — вполне себе живут в OLTP части на одном сервере, в части DWH возможен RAC.
Про тупик для многих компаний было бы интересно почитать.
Самые объемные и нагруженные БД, имхо, моибльных операторов — вполне себе живут в OLTP части на одном сервере, в части DWH возможен RAC.
А почему не сможет?
Привидите пример такой системы.
Ответьте сначала на мой вопрос.
Хорошо. Очевидно, что необходимо наличие энерго-независимой памяти.
По вашей логике только БД является единственно правильным и единственным местом хранения данных, чтобы поддерживать консистентность и исключительность данных. Логика имеет место быть. Но даже у БД есть слабое место, если по каким-то причинам redo-лог не был записан, то транзакция не свершится.
Да, redo- самое слабое место. Именно поэтому до сих пор несмотря на наличие всяческих рэйдов и репликаций на уровне массивов oracle рекомендует создавать как минимум два лога в каждой группе :)
Ну развели флейм.
В интерпрайзе такие системы и проблемы сплошь и рядом, и ничего, проблемы целостности решаются. Не обязательно на «аппаратном» уровне, если это невозможно, то в ход идут административные, организационные и прочие решения.
Например, любая карточная система: там в любой транзакции не то что базы разные, а целые системы, как минимум банк плательщика — карточная система — банк продавца. И ничего, платежи как-то ходят, и товары покупаются )
В интерпрайзе такие системы и проблемы сплошь и рядом, и ничего, проблемы целостности решаются. Не обязательно на «аппаратном» уровне, если это невозможно, то в ход идут административные, организационные и прочие решения.
Например, любая карточная система: там в любой транзакции не то что базы разные, а целые системы, как минимум банк плательщика — карточная система — банк продавца. И ничего, платежи как-то ходят, и товары покупаются )
Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя
en.wikipedia.org/wiki/Distributed_transaction
Бизнес правило: при нажатии купить с счёта клиента списываются деньги, на ваш поступают, операции должны пройти атомарно.
Реализовать данное правило без введения понятия согласованости невозможно.
Реализовать данное правило без введения понятия согласованости невозможно.
Вы оперируете терминами не бизнес-логики, а логики хранения. В терминах бизнес-логики задача звучит типа «провести платеж (обновив баланс)».
Лично я минусов не ставил. Бизнес-логика — это абстрактное понятие, оно не привязано ни к какому языку программирования. Привязка сотрудника к отделу не является бизнес-логикой, это структурная модель. А вот правила перехода сотрудника из отдела к отделу — вот это уже бизнес-логика.
ну как-то же в коде описывается проверка правильности перехода сотрудников из отдела в отдел. Точно также эти правила могут быть описаны в структуре данных.
Именно для этого и существует такое понятие как «нормализация». И именно поэтому существует Оракл и Постгрес.
Именно для этого и существует такое понятие как «нормализация». И именно поэтому существует Оракл и Постгрес.
Проверка правильности заложена в бизнес-логике. Но эту проверку невозможно рассмотреть из структуры данных. К примеру, у вас связь один ко многим для отдела и его работников. Исходя из структуры таблиц можно легко сделать вывод, что можно всех работников сделать уборщиками или директорами. Это позволяет структура хранения данных. Но на практике есть правила, которые формируются за пределами БД.
Нормализация — это естественное желание сделать структуру хранения данных как можно более универсальной, готовой к любым изменениям и расширениям. Но за универсальность приходится платить высокое пенальти по скорости
Нормализация — это естественное желание сделать структуру хранения данных как можно более универсальной, готовой к любым изменениям и расширениям. Но за универсальность приходится платить высокое пенальти по скорости
Покажите мне большую и полностью нормализованную базу… и я сразу скажу, что у неё никогда не было проблем с работой под нагрузкой.
Стоит её загрузить и закормить — они появятся и, скорее всего будут решены денормализацией и деструктуризацией.
Хозяйке на заметку, кэширование — это тоже в некотором роде денормализацияю
Стоит её загрузить и закормить — они появятся и, скорее всего будут решены денормализацией и деструктуризацией.
Хозяйке на заметку, кэширование — это тоже в некотором роде денормализацияю
И в Oracle денормализация реализована из коробки. Явно их задолбали клиенты этим требованием.
Это Вы о чём именно говорили? Где она там?
Поясните, пожалуйста, как они связаны с денормализацией
Денормализация — процесс, обратный нормализации. Превращение хранения данных из нормальной формы, где, в идеале, все данные хранятся в единственном числе, в вид, когда данные могут храниться в готовыми к употреблению, в том числе в виде склеек. MV позволяет денормализировать данные, обновлять их при изменении исходных данных.
Понятно, спасибо.
К сожалению, как средство денормализации материализованные вьюхи дороговаты. Если нужно продублировать одну колонку, дешевле добавить её напрямую и поддерживать программно, чем делать нормализованную табличку без этой колонки и рядом строить вьюху, содержащую её полную копию с нужным дублем колонки из другой таблицы…
К сожалению, как средство денормализации материализованные вьюхи дороговаты. Если нужно продублировать одну колонку, дешевле добавить её напрямую и поддерживать программно, чем делать нормализованную табличку без этой колонки и рядом строить вьюху, содержащую её полную копию с нужным дублем колонки из другой таблицы…
Как раз для дублирования колонки материализованая вьюха и подходит лучше всего. Ведь вас никто не ограничивает создавать две или более вьюх. Мало того, программно поддерживать — это снова же часть сути MV. Количество телодвижений при «программной поддержке» и MV одинаковое, а профита от последнего варианта — в разы больше.
таблица Отделы и таблица Сотрудники имеющая ссылку на отдел. Такая структура однозначно описывает бизнес-правило «каждый сотрудник должен принадлежать какому-то отделу».
А как насчет, скажем, бизнес-правила «В отдел N с такого-то числа запрещается вводить новых сотрудников»? Сможете описать эту бизнес-логику через структуру таблиц (см. ваше «в реляционных базах данных сама структура таблиц уже является описанием бизнес-логики»)?
В том-то и дело что сможет.
Вы тут минусите не мне, а ораклу, за который платят "$47k за ядро" и оно стоит тех денег. Иначе б никто не покупал.
Вы тут минусите не мне, а ораклу, за который платят "$47k за ядро" и оно стоит тех денег. Иначе б никто не покупал.
«оно стоит тех денег» — очень общее понятие, включает в себя не только технические возможности (о которых говорится в статье), но и всякие другие. Например orablog.ru/archives/category/oracle/jdedwards
По-хорошему, конечно нужно считать расходы тщательно, прежде чем покупать.
По-хорошему, конечно нужно считать расходы тщательно, прежде чем покупать.
Т.е. Оракл сможет? Только на структурах — без триггеров? А что-нибудь посложнее? Типа «Все сотрудники отделов, принесших доход в предыщем месяце более N рублей, 10 числа следующего месяца получают по K% премии»?
P.S. Я минусить в принципе не могу (см. карму).
P.S. Я минусить в принципе не могу (см. карму).
Оракл много чего может. Как и Постгрес.
Но вопрос некорректен. Надо «может ли это быть задано структурой и связями данных?». Ответ — да, может.
Но вопрос некорректен. Надо «может ли это быть задано структурой и связями данных?». Ответ — да, может.
1. Чем некорректен?
2. Напомню, что раньше вы говорили лишь о структурах данных (см. ваше «в реляционных базах данных сама структура таблиц уже является описанием бизнес-логики»). Теперь у вас появилось дополнительное понятие — «связи данных». Что вы в него включаете? Primary/foreign keys или вообще любой код на сервере, используемый в операциях над данными?
2. Напомню, что раньше вы говорили лишь о структурах данных (см. ваше «в реляционных базах данных сама структура таблиц уже является описанием бизнес-логики»). Теперь у вас появилось дополнительное понятие — «связи данных». Что вы в него включаете? Primary/foreign keys или вообще любой код на сервере, используемый в операциях над данными?
1. Оракл это только один из представителей SQL-серверов. Поэтому спрашивать только про оракл некорректно — все могут, не только он.
2. Реляционная алгебра (основа серверов и языка SQL ) оперирует аттрибутами, кортежами и отношениями. В просторечье это поля, таблицы и связи.
2. Реляционная алгебра (основа серверов и языка SQL ) оперирует аттрибутами, кортежами и отношениями. В просторечье это поля, таблицы и связи.
Я знаю, что такое реляционная алгебра — не надо мне объяснять.
Лучше бы объяснили, как в SQL команды определения структур данных (напомню еще раз — вы говорили о чудесной возможности описать бизнес-логику структурами таблиц) помогут вам решить упомянутую мной задачу («Все сотрудники отделов, принесших доход в предыщем месяце более N рублей, 10 числа следующего месяца получают по K% премии»).
И еще: код, который вам придется для этого написать, не имеет никакого отношения к термину «отношения» («в просторечье связи») в реляционной алгебре (пардон за тавтологию).
Лучше бы объяснили, как в SQL команды определения структур данных (напомню еще раз — вы говорили о чудесной возможности описать бизнес-логику структурами таблиц) помогут вам решить упомянутую мной задачу («Все сотрудники отделов, принесших доход в предыщем месяце более N рублей, 10 числа следующего месяца получают по K% премии»).
И еще: код, который вам придется для этого написать, не имеет никакого отношения к термину «отношения» («в просторечье связи») в реляционной алгебре (пардон за тавтологию).
Объяснить? Да легко.
Но не в этой теме.
Кто хочет может создать топик вроде «Ущербность реляционных баз данных» и там выдвинуть тезисы о невозможности решить «упомянутую задачу» средствами SQL. Привести там примеры решения этой же задачи на любом языке программирования и удивиться элегантности решения её же средствами SQL.
Формат Хабрабра таков что любое мнение не совпадающее с любыми, даже самыми дилетантскими мифами, ведёт к минусованию. В таком формате сложно приводить какие-то доводы. Метание бисера напоминает.
Но не в этой теме.
Кто хочет может создать топик вроде «Ущербность реляционных баз данных» и там выдвинуть тезисы о невозможности решить «упомянутую задачу» средствами SQL. Привести там примеры решения этой же задачи на любом языке программирования и удивиться элегантности решения её же средствами SQL.
Формат Хабрабра таков что любое мнение не совпадающее с любыми, даже самыми дилетантскими мифами, ведёт к минусованию. В таком формате сложно приводить какие-то доводы. Метание бисера напоминает.
«отношения» («в просторечье связи») в реляционной алгебремм… «отношения» в просторечье это «множества». а связи между ними определяются операторами, которые используются в выражении.
Вы путаете предметную область и бизнес-логику.
Структура таблиц является описанием терминов, понятий и отношений предметной области. А бизнес-логика описывает алгоритмы, процессы, правила предметной области, в применении к понятиям и отношениям предметной области.
Бизнес-логика может быт реализована, например, на PHP/Python/Ruby/Java/PLSQL/whatever. А таблицы описаны и храниться в RDBMS. Или в каком-нибудь NoSQL (тут «No» в значении «No», а не «Not Only»). Языком общения этих двух штук является SQL или какой-нибудь иной самодельный API.
Структура таблиц является описанием терминов, понятий и отношений предметной области. А бизнес-логика описывает алгоритмы, процессы, правила предметной области, в применении к понятиям и отношениям предметной области.
Бизнес-логика может быт реализована, например, на PHP/Python/Ruby/Java/PLSQL/whatever. А таблицы описаны и храниться в RDBMS. Или в каком-нибудь NoSQL (тут «No» в значении «No», а не «Not Only»). Языком общения этих двух штук является SQL или какой-нибудь иной самодельный API.
Еще пара плюсов в сторону PostgreSQL: http://habrahabr.ru/post/45475/ и http://wiki.postgresql.org/wiki/PGQ_Tutorial
Пару лет работаю с PostgreSQL. Нравится и стабильность и возможности СУБД.
А никто случаем с Oracle на MS SQL не переходил?
Что можно сказать про T-SQL?
Что можно сказать про T-SQL?
Вам будет не хватать произвольной конвертации значений по маске (в стиле to_date(), to_char()) и подобных мелочей. А в целом нормально.
Я сейчас перехожу. Могу сказать что будет нехватать очень много чего.
Начиная прямо с типа tinyint, который можно правда заменить доменом.
Еще было удивительно поведение unique index с null полями. В MS SQL это настраивается c помощью ANSI NULLS и по умолчанию не соответствует стандарту, в постгре же по стандарту и не настраивается. По стандарту null != null и следовательно если в наборе полей включенных в unique индекс есть хоть 1 null то вы можете вставить сколько угодно таких наборов.
Механизм хранения больших двоичных данных тоже… не такой как везде.
Вообще много разных фокусов, могу если будет много желающих статью написать. Но в целом жить можно.
Начиная прямо с типа tinyint, который можно правда заменить доменом.
Еще было удивительно поведение unique index с null полями. В MS SQL это настраивается c помощью ANSI NULLS и по умолчанию не соответствует стандарту, в постгре же по стандарту и не настраивается. По стандарту null != null и следовательно если в наборе полей включенных в unique индекс есть хоть 1 null то вы можете вставить сколько угодно таких наборов.
Механизм хранения больших двоичных данных тоже… не такой как везде.
Вообще много разных фокусов, могу если будет много желающих статью написать. Но в целом жить можно.
Пакетов в PostgreSQL очень не хватает.
А кто-нибудь работал с коммерческим Postgres (ака EnterpriseDB Advanced Server )? Судя по рекламе там очень много вкусностей именно для переходящих с Oracle (планировщик задач в БД, нормальное секционирование таблиц, пакеты для процедур и т.д.), насколько не врет реклама?
В процедурах на PL/pgSQL есть явное управление транзакциями (через исключения). Путем организации блока begin/exception/end можно создавать подтранзакции, и откатывать или коммитить их по отдельности.
Коммитить-то как раз нельзя (в том смысле, чтобы гарантировать фиксацию изменений в данных до выхода из функции). Вообще за явный коммит внутри процедуры надо в большинстве случаев рвать пинцетом волосы в межягодичной впадине.
Да, коммит родительской транзакции из процедуры, выполняющейся в ее же рамках, разумеется, невозможен.
Если хочется из функции открывать новые top-level транзакции, то инструменты вроде plproxy (используется autocommit, все очень удобно но явного управления транзакцией нет) или dblink (не очень удобно, но можно явно начинать/коммитить/откатывать транзакцию) в помощь.
Если хочется из функции открывать новые top-level транзакции, то инструменты вроде plproxy (используется autocommit, все очень удобно но явного управления транзакцией нет) или dblink (не очень удобно, но можно явно начинать/коммитить/откатывать транзакцию) в помощь.
Автор, рекомендую для небольших проектов посмотреть еще в сторону Firebird. По развитости SQL и PSQL лишь немного уступает, но зато гораздо легче сама по себе. + Есть локальный embedded-вариант в виде DLL но с абсолютно теми же возможностями что и server.
Стабильная?
Вполне
Какие плюшки?
в нем конечно нет пакетов, партиционирования и пр. но то что заявлено работает и работает предсказуемо.
Мне кажется, основной плюс FB — минимальные затраты на администрирование и возможность работы на чем угодно.
Делает программу, которая должна быть установлена на другом конце страны, неизвестно кем и на каком оборудовании — выбирайте FB. Если же это высоконагруженный сервер приложений, работающий у вас под присмотром, то Postgre SQL, хотя, конечно, в таких случаях факторов влияющих на выбор может быть много.
Делает программу, которая должна быть установлена на другом конце страны, неизвестно кем и на каком оборудовании — выбирайте FB. Если же это высоконагруженный сервер приложений, работающий у вас под присмотром, то Postgre SQL, хотя, конечно, в таких случаях факторов влияющих на выбор может быть много.
В качестве легковестного SQL для программы, которая будет установлена фиг знает где, можно использовать и SQLite.
SQLite — жуткий тормоз на запись. Был по крайней мере пару лет назад. Сейчас может поправили.
Мягко говоря, странное заявление.
Возможно связано с непониманием механизма транзакций SQLite?..
Возможно связано с непониманием механизма транзакций SQLite?..
Кстати, да. Я когда проверял намеренно вставлял каждую строку в отдельной транзакции. Но в тех же условиях Postgres был на примерно два порядка быстрее.
Postgres не был «в тех же условиях».
SQLIte гарантирует, что после возврата из вызова (в котором фиксируется транзакция и при использовании синхронизации FULL) можно выдернуть шнур из питания и данные не пропадут.
Postgres же «делает вид», что данные зафиксированы на диске. Не знаю подробностей, но думаю он использует что-то подобное MS SQL с отложенной фиксацией транзакции на диске.
Т.е. если после возврата вызова (для Postgres) выдернуть шнур — данные пропадут.
SQLIte гарантирует, что после возврата из вызова (в котором фиксируется транзакция и при использовании синхронизации FULL) можно выдернуть шнур из питания и данные не пропадут.
Postgres же «делает вид», что данные зафиксированы на диске. Не знаю подробностей, но думаю он использует что-то подобное MS SQL с отложенной фиксацией транзакции на диске.
Т.е. если после возврата вызова (для Postgres) выдернуть шнур — данные пропадут.
SQLite отличная штука, для однопользовательских и действительно простых задач. Офигенно компактная и быстрая. У Firebird сегмент более сложных многопользовательских приложений, но не корпоративного сегмента, а попроще. Фактически это разные весовые категории.
В качестве легковестного SQL для программы, которая будет установлена фиг знает где, можно использовать и SQLite.
Тоже вариант.
FB в качестве встроенного сервера выбирают в основном те, кто работал с обычной версией. У FB Embedded есть один весомый плюс — он ничем не отличается от обычного и одно и тоже приложение может работать как с локальной БД так и с удаленной.
Да, к плюшкам можно отнести IBExpert — IDE для Firebird и Interbase. Это пожалуй лучшая IDE среди вообще всех IDE для РСУБД. И она бесплатна для exUSSR.
Судя по тому, что автор переходит с Oracle вряд ли речь идет о домашней странице Васи Пупкина. Для небольших проектов необходимости писать хранимые процедуры как правило нет.
Ну как небольшие, я занимался проектом около полумиллиона строк, там FB был именно тем что нужно, ХП использовались очень активно. Дело в том, что FB гораздо менее требователен к ресурсам на малых объемах данных, что очень важно для слабого оборудования (POS-терминалы, например).
никто не советовал FB для домашней страницы, у не него другая ниша.
Заходя в топик, прихватил кусок арматуры. Оказалось, не нужен.
В чем же заключается «недоразвитости процедурного языка» в mysql? Не холивара ради, а в целях расширения кругозора?
Очень интересная дискуссия относительно бизнес логики. Расскажу два случая.
Я работал в ВЦ ГТК (Таможенное управление) и мы внедряли систему АИСТ (автоматизированная система таможни), наш исполнитель начал разрабатывать систему АИСТ на Ms SQL Server, как временное решение, так как для него лицензионный Oracle был дорог. Хочу пояснить, что в соответствии с регламетом Гостехкомиссии, все данные должны были хранится в Oracle, на то время 2000г, Oracle во время подсуетились, и только эта РСБД прошла Сертификацию и была рекомендована для внедрения в Госорганах.
Так вот, исполнитель начал разработку под SQL сервер и обещал, что как только они приобретут лицензию на Оракл, то быстро переведут систему на другую СУБД. Прошло три года, наступил этап передачи Программного обеспечения. К этому времени оказалось, что написано более 3000 ХП и для перевода на Оракл понадобится еще пол года разработки. Так что потом пришлось писать кучу писем на разрешение использовать Ms SQL.
Вторая история: когда-то я работал я в tradebox.ru
Наш бывший архитектор, до этого разрабатывал Interprise решения на базе Оракл, и решил перенести эту архитектуру на небольшой WEB проект на базе MySQL.
Большую часть бизнес логики решил реализовать на ХП.
Мы долго искали SQL программиста, часть хранимок писал он сам. В итоге разработка из 6-9 мес затянулась более чем на год. Было написано более 50 ХП.
В результате оказалось, что MySQL не справляется с бизнес логикой, постоянно возниакют
deadlockи, очереди необработанных сообщений стали расти. В общем, проект был загублен плохой архитектурой…
Я работал в ВЦ ГТК (Таможенное управление) и мы внедряли систему АИСТ (автоматизированная система таможни), наш исполнитель начал разрабатывать систему АИСТ на Ms SQL Server, как временное решение, так как для него лицензионный Oracle был дорог. Хочу пояснить, что в соответствии с регламетом Гостехкомиссии, все данные должны были хранится в Oracle, на то время 2000г, Oracle во время подсуетились, и только эта РСБД прошла Сертификацию и была рекомендована для внедрения в Госорганах.
Так вот, исполнитель начал разработку под SQL сервер и обещал, что как только они приобретут лицензию на Оракл, то быстро переведут систему на другую СУБД. Прошло три года, наступил этап передачи Программного обеспечения. К этому времени оказалось, что написано более 3000 ХП и для перевода на Оракл понадобится еще пол года разработки. Так что потом пришлось писать кучу писем на разрешение использовать Ms SQL.
Вторая история: когда-то я работал я в tradebox.ru
Наш бывший архитектор, до этого разрабатывал Interprise решения на базе Оракл, и решил перенести эту архитектуру на небольшой WEB проект на базе MySQL.
Большую часть бизнес логики решил реализовать на ХП.
Мы долго искали SQL программиста, часть хранимок писал он сам. В итоге разработка из 6-9 мес затянулась более чем на год. Было написано более 50 ХП.
В результате оказалось, что MySQL не справляется с бизнес логикой, постоянно возниакют
deadlockи, очереди необработанных сообщений стали расти. В общем, проект был загублен плохой архитектурой…
а есть положительный пример перевода системы такого же размера как АИСТ? Отрицательных много можно привести на разных технологиях, и с базами данных и без них.
Положительных чёто мало. Причём даже если всё принято и деньги заплачены.
Положительных чёто мало. Причём даже если всё принято и деньги заплачены.
Большую часть бизнес логики решил реализовать на ХП.
В MySQL? Наркоманы?
Вы зря так категорично относитесь к mysql. Если сравнить постгрес и мускль, то можно заметить, что и там, и там есть как плюсы, так и минусы. И по их количеству паритет. Ведь не зря его использует такое кол-во людей. И facebook, вконтакте начинали (и сейчас продолжают использовать, но не в полной мере) именно с mysql. Либо все вокруг дураки и не знают что есть куда лучший инструмент — постгрес, либо у вас предвзятое отношение. Я сейчас работаю в организации, где основная база мускуль. Нагрузка на нее создается приличная. Используется секционирование, часть логики (работа с деньгами, например) написана на хп. Все кешируется в мемкеш + грамотное использование индексов. Все это дает приличный запас прочности проекту. Поэтому дело не в инструменте, а в руках, его использующих.
Вы зря так категорично относитесь к mysql. Если сравнить постгрес и мускль, то можно заметить, что и там, и там есть как плюсы, так и минусы. И по их количеству паритет.
Я работал и с тем и тем. И если у меня есть выбор между СУБД я всегда выберу PostgreSQL. В MySQL очень много всяких раздражающих факторов. Один из главных это глобальные блокировки и адово низкая производительность при большом числе параллельной записи.
Ведь не зря его использует такое кол-во людей.
Как правило эти люди или не видели других СУБД или ее выбрали за них.
Я сейчас работаю в организации, где основная база мускуль. Нагрузка на нее создается приличная.
Увы не показатель. С MySQL сильнее приходится прыгать с бубном и быть существенно более аккуратным при написании запросов.
Используется секционирование, часть логики (работа с деньгами, например) написана на хп.
Ключевой момент во первых часть логики. Во вторых я не думаю что у вас хранимка работает долго. И у вас явно нет длинных транзакций.
Все кешируется в мемкеш + грамотное использование индексов.
Если у вас так все хорошо работает зачем вам memcache?
Поэтому дело не в инструменте, а в руках, его использующих.
Вот возьмите и попробуйте тоже самое сделать на PostgreSQL и вы удивитесь насколько там многие вещи сделаны удобнее и лучше.
Я тоже работал и с тем и другим. Да, согласен, что где-то приходится прыгать с бубном, но разве в постгресе не так?
1. Адово низкая производительность? Что для Вас адово низкая? Не замечал такого. Может просто не стоит увешивать таблицу, в которую много пишут огромным количеством индексов? Не знаю, может еще какие-то причины у вас были.
2. Очень сильно сомневаюсь, но утверждать не буду
3. Тоже работал с постгресом и не скажу, что танцев было меньше
4. Я не считаю необходимым переносить всю логику в базу. Здесь уже куча подобных комментов заминусовали, но я с ними соглашусь. База не должна быть нагружена логикой. В первую очередь это хранилище данных. По поводу долгих хранимок согласен. Но опять же, субд — не сервер для выполнения нереальных обработок, стоит как-то оптимизировать.
5. Ну как минимум потому, что мемкеш хранит все данные в памяти (оперативная память быстрее жестких дисков). Но главное — мемкеш это хештаблица со скоростью доступа к данным не зависящим от кол-ва этих самых даных, т.е. O(1). Ни одна реляционная СУБД этим похвастаться не может. Так зачем я буду лишний раз тревожить СУБД по одному и тому же вопросу, если она мне один раз уже ответила.
6. Удобство — очень субъективный фактор.
1. Адово низкая производительность? Что для Вас адово низкая? Не замечал такого. Может просто не стоит увешивать таблицу, в которую много пишут огромным количеством индексов? Не знаю, может еще какие-то причины у вас были.
2. Очень сильно сомневаюсь, но утверждать не буду
3. Тоже работал с постгресом и не скажу, что танцев было меньше
4. Я не считаю необходимым переносить всю логику в базу. Здесь уже куча подобных комментов заминусовали, но я с ними соглашусь. База не должна быть нагружена логикой. В первую очередь это хранилище данных. По поводу долгих хранимок согласен. Но опять же, субд — не сервер для выполнения нереальных обработок, стоит как-то оптимизировать.
5. Ну как минимум потому, что мемкеш хранит все данные в памяти (оперативная память быстрее жестких дисков). Но главное — мемкеш это хештаблица со скоростью доступа к данным не зависящим от кол-ва этих самых даных, т.е. O(1). Ни одна реляционная СУБД этим похвастаться не может. Так зачем я буду лишний раз тревожить СУБД по одному и тому же вопросу, если она мне один раз уже ответила.
6. Удобство — очень субъективный фактор.
Адово низкая производительность? Что для Вас адово низкая? Не замечал такого. Может просто не стоит увешивать таблицу, в которую много пишут огромным количеством индексов? Не знаю, может еще какие-то причины у вас были.
В два раза хуже чем PostgreSQL на операциях массовой записи.
Тоже работал с постгресом и не скажу, что танцев было меньше
Ну расскажите тогда про танцы. Я вот обычно смотрю количество памяти на сервере и настраиваю 4 параметрам в PostgreSQL и все. Дальше работаю с ним.
Я не считаю необходимым переносить всю логику в базу. Здесь уже куча подобных комментов заминусовали, но я с ними соглашусь.
Зависит от того что делает эта логика. Если она активно лопатит данные в СУБД, лучше делать хранимкой. Будет работать намного быстрее.
База не должна быть нагружена логикой. В первую очередь это хранилище данных.
Логика в СУБД должна присутствовать, но в первую очередь она должна быть направлена на поддержание консистентности данных
По поводу долгих хранимок согласен. Но опять же, субд — не сервер для выполнения нереальных обработок, стоит как-то оптимизировать.
В PostgreSQL это не так мешает жить. И за все время своей работы с PostgreSQL я сталкивался с не возможностью завершить операцию только один раз. В MySQL на эти грабли наступаешь постоянно.
Ну как минимум потому, что мемкеш хранит все данные в памяти (оперативная память быстрее жестких дисков).
Рассказываю страшную тайну, если у вас СУБД не может разместить часто используемые данные и индексы в имеющуюся память у вас все будет адово тормозить.
Удобство — очень субъективный фактор.
Я бы не сказал.
У меня такое ощущение, что вы начинаете грубить («страшная тайна», которую вы мне открыли). Поверьте у меня не мало опыта работы с различными СУБД, хоть и не со всеми и возможно меньше чем у вас. Я никогда не работал с оракл, но поработал с: постгресом, мускулем, монго, коуч, редис, беркли. Если вы выбрали такой тон, то:
1. Интересно посмотреть на тесты. Пока это голые слова. Вполне возможно, что так и есть, но подтверждений этому не вижу
2. С установкой мускуля танцев как таковых вообще нет. Конфиг под сервер и все. Я говорил про танцы, например при секционировании, при создании индексов, при синхронизации и репликациях.
3. Согласен и придерживаюсь такого же мнения. Но я говорил не про кол-во перебираемых строк, а про сложность самой логики. Она должна быть простой: перебрать все строки в таблице и найти минимум (понимаю, что это делается MIN, но более сложный и адекватный пример лень придумывать))
4. Опять же согласен
5. Ну при желании можно и и не так извратиться, но тут все таки скорее размазывание кода. То что это не мешает вам жить — временное явление, например, пока не наступит этап рефакторинга или изменения старого функционала.
6. Рассказываю страшную тайну вам: на высоконагруженных проекта редко используют один сервер подо все. Мемкеш, статика с нджинксом, динамика и мускуль — все на разных серверах. Мало того этих серверов несколько. Для мемкеша используется консистентный хеш и построен кластер, мускуль юзает шардинг.
7. Ну раз не субъективный, то мне удобно работать с мускулем. Если исходить из объективности моего мнения, то значит и вам это также должно быть удобно )
1. Интересно посмотреть на тесты. Пока это голые слова. Вполне возможно, что так и есть, но подтверждений этому не вижу
2. С установкой мускуля танцев как таковых вообще нет. Конфиг под сервер и все. Я говорил про танцы, например при секционировании, при создании индексов, при синхронизации и репликациях.
3. Согласен и придерживаюсь такого же мнения. Но я говорил не про кол-во перебираемых строк, а про сложность самой логики. Она должна быть простой: перебрать все строки в таблице и найти минимум (понимаю, что это делается MIN, но более сложный и адекватный пример лень придумывать))
4. Опять же согласен
5. Ну при желании можно и и не так извратиться, но тут все таки скорее размазывание кода. То что это не мешает вам жить — временное явление, например, пока не наступит этап рефакторинга или изменения старого функционала.
6. Рассказываю страшную тайну вам: на высоконагруженных проекта редко используют один сервер подо все. Мемкеш, статика с нджинксом, динамика и мускуль — все на разных серверах. Мало того этих серверов несколько. Для мемкеша используется консистентный хеш и построен кластер, мускуль юзает шардинг.
7. Ну раз не субъективный, то мне удобно работать с мускулем. Если исходить из объективности моего мнения, то значит и вам это также должно быть удобно )
1. Интересно посмотреть на тесты. Пока это голые слова. Вполне возможно, что так и есть, но подтверждений этому не вижу
Такое тестирование в свое время проводил slonik-v-domene
У себя я тестировал таким ПО как zabbix. Он довольно активно работает с СУБД. У него как раз профиль нагрузки перекошен на запись обновление и удаление. Простой пример. Когда zabbix начинал чистить старые данные, то в случае MySQL все операции записи вставали колом. В случае PostgreSQL на той же машине все работало.
2. С установкой мускуля танцев как таковых вообще нет. Конфиг под сервер и все. Я говорил про танцы, например при секционировании, при создании индексов, при синхронизации и репликациях.
Вообще речь идет про настройку MySQL под конкретную машину и там ручек на порядок больше чем в PostgreSQL. Причем частенько их еще крутить надо не тривиальным образом.
Рассказываю страшную тайну вам: на высоконагруженных проекта редко используют один сервер подо все. Мемкеш, статика с нджинксом, динамика и мускуль — все на разных серверах.
Я в курсе. Просто сейчас для MySQL есть замечательный плагин который позволяет его использовать как NoSQL. В результате memcached можно вообще не ставить.
мускуль юзает шардинг.
Это кстати частая причина почему его используют. Плюс типичный конфиг MySQL в таком случае это пишем на один читаем на другом.
то мне удобно работать с мускулем.
Вы как нибудь попробуйте написать аналитический запрос с вложенными запросами в MySQL ну так чтобы данных по декартовому произведению было хотя бы с миллион. Вот тогда будет не очень удобно работать с MySQL. У него отвратительный анализатор за счет этого приходится часто в работе смотреть explain и изменять запрос.
1. Ничего не могу ответить. Возможно так есть, но я с таким пока не сталкивался, хотя тоже использую заббикс
2. Опять же не сталкивался с чем-то нетривиальным. Мне всегда хватало документации, чтобы настроить сервер под конкретную машину
3. Не совсем понял как ваш ответ относится к цитируемой фразе.
4. Ну так я кажется в самом начале спора сказал, что обе СУБД обладают и минусами, и плюсами. И плюсы мускуля перевешивают плюсы постгреса для текущего проекта
5. Писал. Декартово произведение давало 20 млнов записей. И пришлось изобретать нетривиальный способ сделать такой запрос (кусками по сотне тысяч). А про анализатор… За всю жизнь долго втуплял в эксплейн всего один раз, когда по ошибке было создано 2 индекса, которые перекрывали друг друга, но один был менее эффективен. В том случае анализатор выбирал каким-то магическим образом то один, то другой индекс. Дело не в его ужасности, просто у него есть нюансы, которые достаточно быстро можно понять.
2. Опять же не сталкивался с чем-то нетривиальным. Мне всегда хватало документации, чтобы настроить сервер под конкретную машину
3. Не совсем понял как ваш ответ относится к цитируемой фразе.
4. Ну так я кажется в самом начале спора сказал, что обе СУБД обладают и минусами, и плюсами. И плюсы мускуля перевешивают плюсы постгреса для текущего проекта
5. Писал. Декартово произведение давало 20 млнов записей. И пришлось изобретать нетривиальный способ сделать такой запрос (кусками по сотне тысяч). А про анализатор… За всю жизнь долго втуплял в эксплейн всего один раз, когда по ошибке было создано 2 индекса, которые перекрывали друг друга, но один был менее эффективен. В том случае анализатор выбирал каким-то магическим образом то один, то другой индекс. Дело не в его ужасности, просто у него есть нюансы, которые достаточно быстро можно понять.
Ничего не могу ответить. Возможно так есть, но я с таким пока не сталкивался, хотя тоже использую заббикс
У меня узлов не маленько. По этой причине данных много.
Опять же не сталкивался с чем-то нетривиальным. Мне всегда хватало документации, чтобы настроить сервер под конкретную машину
Почитайте www.mysqlperformanceblog.com/ узнаете много нового.
3. Не совсем понял как ваш ответ относится к цитируемой фразе.
Во многих случаях memcached можно будет и не использовать.
4. Ну так я кажется в самом начале спора сказал, что обе СУБД обладают и минусами, и плюсами. И плюсы мускуля перевешивают плюсы постгреса для текущего проекта
И какие же там плюсы?
5. Писал. Декартово произведение давало 20 млнов записей. И пришлось изобретать нетривиальный способ сделать такой запрос (кусками по сотне тысяч).
И работало это явно весьма не быстро.
А про анализатор… За всю жизнь долго втуплял в эксплейн всего один раз, когда по ошибке было создано 2 индекса, которые перекрывали друг друга, но один был менее эффективен. В том случае анализатор выбирал каким-то магическим образом то один, то другой индекс. Дело не в его ужасности, просто у него есть нюансы, которые достаточно быстро можно понять.
А вы его почаще открываете и увидите как он работает. Он реально ужасен. Часто бывает достаточно переставить параметры местами.
Читал. Но я не считаю это танцами с бубном, ведь все это детально описано в документации. Просто мало кто читает документацию и потом кричит, что все неочевидно.
Почитайте все таки на википедии что такое хеш-таблица (ссылку давать не буду, найти легко) и в чем ее преимущество. Не исключено, что плагин вносит какие-то кардинальные изменения и реализуется именно хеш-таблицы на базе мускуля, но смысл с такого решения, если есть специализированные системы?
Да хотя бы такие, что я смог в документации найти подробное описание как настроить шардинг и оптимизировать его работу настолько, что запаса прочности хватит еще на долго. В постгресе все как-то совсем нетривиально и «неудобно» для меня.
Вы не правы. Это работало очень быстро. Скорость выборки была log по основанию 2 от N, так как использовался бинарные операции сокращения массива данных и сортировки на основе индекса.
Зачем? Я прочитал документацию в которой понятно объяснено почему именно в таком порядке должны быть параметры и делаю так, что эксплэйн ничего интересного не показывает. Читайте документацию.
И давайте закончим спор, а то судя по вашему тону вы уже близки к тому, чтобы перейти на личности. Я всего лишь сказал, что не стоит так категорично относится к инструменту, потому что может оказаться, что вы не настолько глубоко его знаете и используете неправильно. Для меня такая ситуация, например, с Постгресом. Я не знаю как там сделать шардинг по-человечески, так как не смог найти этого в доках, но это не говорит, что инструмент говно.
Почитайте все таки на википедии что такое хеш-таблица (ссылку давать не буду, найти легко) и в чем ее преимущество. Не исключено, что плагин вносит какие-то кардинальные изменения и реализуется именно хеш-таблицы на базе мускуля, но смысл с такого решения, если есть специализированные системы?
Да хотя бы такие, что я смог в документации найти подробное описание как настроить шардинг и оптимизировать его работу настолько, что запаса прочности хватит еще на долго. В постгресе все как-то совсем нетривиально и «неудобно» для меня.
Вы не правы. Это работало очень быстро. Скорость выборки была log по основанию 2 от N, так как использовался бинарные операции сокращения массива данных и сортировки на основе индекса.
Зачем? Я прочитал документацию в которой понятно объяснено почему именно в таком порядке должны быть параметры и делаю так, что эксплэйн ничего интересного не показывает. Читайте документацию.
И давайте закончим спор, а то судя по вашему тону вы уже близки к тому, чтобы перейти на личности. Я всего лишь сказал, что не стоит так категорично относится к инструменту, потому что может оказаться, что вы не настолько глубоко его знаете и используете неправильно. Для меня такая ситуация, например, с Постгресом. Я не знаю как там сделать шардинг по-человечески, так как не смог найти этого в доках, но это не говорит, что инструмент говно.
Читал. Но я не считаю это танцами с бубном, ведь все это детально описано в
документации.
Увы не детально. По сути дела гайда как хорошо настроить СУБД там нет. Там есть максимум описание опций. Как их свести так чтобы все работало лучше увы нет. Кстати говоря и PostgreSQL нет. Но там есть довольно хороший гайд который говорит какие ручки крутить для достижения результата. И ручек этих меньше чем в MySQL. В MySQL поболее за счет его модульной архитектуры. По этому часто надо сначала покрутить в самом MySQL потом отдельно крутить для движка.
Не исключено, что плагин вносит какие-то кардинальные изменения и реализуется именно хеш-таблицы на базе мускуля, но смысл с такого решения, если есть специализированные системы?
Плагин устраняет трансляцию SQL во внутреннее представление движка. На выходе получаем как раз доступ к таблице как хеш-таблице. Смысл был в том что такое решение давало весьма неплохие результаты.
В постгресе все как-то совсем нетривиально и «неудобно» для меня.
В PostgreSQL аналогично делается. Решения весьма схожи.
Вы не правы. Это работало очень быстро. Скорость выборки была log по основанию 2 от N, так как использовался бинарные операции сокращения массива данных и сортировки на основе индекса.
После усечения и оптимизации запроса под индексы.
Зачем? Я прочитал документацию в которой понятно объяснено почему именно в таком порядке должны быть параметры и делаю так, что эксплэйн ничего интересного не показывает. Читайте документацию.
Вообще говоря есть такая вещь как стандарт SQL92. И вот во многих случаях выборки работающие быстро на том же PostgreSQL и Oracle медленно работают на MySQL по причине того что анализатор лажает. А теперь я вам задам вопрос почему я должен читать документацию и досконально знать что вот тут мне надо вот только таким образом составить запрос если стандарт это не определяет и что не мало важно в других СУБД это работает быстро?
Я всего лишь сказал, что не стоит так категорично относится к инструменту, потому что может оказаться, что вы не настолько глубоко его знаете и используете неправильно.
Я так к этому инструменту отношусь потому что использовал продолжительное время оба инструмента на больших объемах данных. И заметил что под MySQL мне часто приходится подстраиваться из-за его ограничений. В других же СУБД это требуется на много реже.
Я не знаю как там сделать шардинг по-человечески, так как не смог найти этого в доках
Шардинг появился с 9.2 нормальный. Так что не удивительно. До этого слейв мог быть только один. Вертикальный же шардинг делается сторонними средствами от Skype.
Есть такая замечательная книжка «Оптимизация производительности MySQL». Все винтики, которые нужно крутить там шикарно объяснены.
Так и зачем делать такого франкенштейна? Мемкеш тем и хорош, что он прост как пробка и накладные расходы минимальны. Кстати по ссылке на блог (просмотрел весь, но так и не смог найти тесты, может где-то запрятаны) вы можете найти очень хорошие записи про использование кеширования и почему стоит этим пользоваться.
Я не отрицаю. Но Нашел я его в доках по мускулю, а не в доках по постгресу.
А вы предпочитаете не использовать индексы и оптимизацию? Тогда, думаю, не стоит дальше продолжать разговор.
Ладно, приведите пример запроса, которые лажает на мускуле и не лажает на постгресе? Что там так кардинально ломает оптимизатор? 4.5 миллиона пользователей в базе, 200 миллионов чтений и около 50 млн. записи ежедневно. И я ни разу не сталкивался с проблемами в запросах. Как говорил выше один раз всего тупил на эксплейн. А по поводу документации… В этом и проблема большинства людей. Почему вы не кричите гибдд: «Нафиг мне ваши правила, почему я должен подстраиваться под них?!».
Ну вот видите. Когда я выбирал СУБД, то я сделал верный выбор. Зачем мне субд, которая не имеет шардинга, если есть такой замечательный мускуль с шардингом. Сейчас может ситуация изменилась, но не отрицайте, что вы, как и я, не следите за всеми инструментами, даже теми, которые не используете.
Ваше мнение состоит главным образом в том, что для вашей задачи мускуль в некоторых ситуациях подтупливал и вы посчитали его убогим инструментом. У меня аналогичная ситуация была с постгресом (только мне его настроить было сложнее, до тупняков не дошло), но я не считаю, что он хуже мускуля. Ваша проблема в том, что у вас развилась профессиональная слепота, которая приводит к игнорированию других инструментов, так как привыкли работать на этих. Это беда всех программисто, включая меня. Не так давно начал новый проект на монго и это для меня было очень трудно, так как нет привычной реляционности. Меня от этого ломало месяц где-то. Но зато сейчас я понимаю, что оно того стоило. Но не потому что монго лучше мускуля и постгреса. Просто он другой и под другие задачи и справляется с ними на ура.
Так и зачем делать такого франкенштейна? Мемкеш тем и хорош, что он прост как пробка и накладные расходы минимальны. Кстати по ссылке на блог (просмотрел весь, но так и не смог найти тесты, может где-то запрятаны) вы можете найти очень хорошие записи про использование кеширования и почему стоит этим пользоваться.
Я не отрицаю. Но Нашел я его в доках по мускулю, а не в доках по постгресу.
А вы предпочитаете не использовать индексы и оптимизацию? Тогда, думаю, не стоит дальше продолжать разговор.
Ладно, приведите пример запроса, которые лажает на мускуле и не лажает на постгресе? Что там так кардинально ломает оптимизатор? 4.5 миллиона пользователей в базе, 200 миллионов чтений и около 50 млн. записи ежедневно. И я ни разу не сталкивался с проблемами в запросах. Как говорил выше один раз всего тупил на эксплейн. А по поводу документации… В этом и проблема большинства людей. Почему вы не кричите гибдд: «Нафиг мне ваши правила, почему я должен подстраиваться под них?!».
Ну вот видите. Когда я выбирал СУБД, то я сделал верный выбор. Зачем мне субд, которая не имеет шардинга, если есть такой замечательный мускуль с шардингом. Сейчас может ситуация изменилась, но не отрицайте, что вы, как и я, не следите за всеми инструментами, даже теми, которые не используете.
Ваше мнение состоит главным образом в том, что для вашей задачи мускуль в некоторых ситуациях подтупливал и вы посчитали его убогим инструментом. У меня аналогичная ситуация была с постгресом (только мне его настроить было сложнее, до тупняков не дошло), но я не считаю, что он хуже мускуля. Ваша проблема в том, что у вас развилась профессиональная слепота, которая приводит к игнорированию других инструментов, так как привыкли работать на этих. Это беда всех программисто, включая меня. Не так давно начал новый проект на монго и это для меня было очень трудно, так как нет привычной реляционности. Меня от этого ломало месяц где-то. Но зато сейчас я понимаю, что оно того стоило. Но не потому что монго лучше мускуля и постгреса. Просто он другой и под другие задачи и справляется с ними на ура.
Есть такая замечательная книжка «Оптимизация производительности MySQL». Все винтики, которые нужно крутить там шикарно объяснены.
Вот этой презентации достаточно для настройки PostgreSQL. А вот для настройки MySQL действительно желательно почитать целую книгу. Чувствуете разницу?
Так и зачем делать такого франкенштейна? Мемкеш тем и хорош, что он прост как пробка и накладные расходы минимальны.
Это ребята из Percona показывали что во многих случах кеш может не потребоваться.
А вы предпочитаете не использовать индексы и оптимизацию? Тогда, думаю, не стоит дальше продолжать разговор.
Я предпочитаю делать поменьше своими руками. В MySQL часто приходится проводить оптимизацию запроса из-за убогости анализатора. И я бы не сказал что я от этого в восторге.
Ладно, приведите пример запроса, которые лажает на мускуле и не лажает на постгресе? Что там так кардинально ломает оптимизатор?
Самый простой способ залажать MySQL это убрать join перенести все условия в where и задать список таблиц. В любой другой СУБД анализатор это сам поправит. Плюс часто лажает на вложенных селектах, так что приходится выворачивать запрос или мирится с тем что оно работает долго.
Как говорил выше один раз всего тупил на эксплейн.
А мне вот приходится периодически его смотреть. И хорошо если проблема в отсутствующем индексе.
А по поводу документации… В этом и проблема большинства людей. Почему вы не кричите гибдд: «Нафиг мне ваши правила, почему я должен подстраиваться под них?!».
Вы правда верите, что каждый кто работает с MySQL должен знать ее на уровне эксперта? Вообще говоря СУБД это системы общего пользования и у них есть стандарт SQL92. И строго говоря разработчика должны мало волновать тараканы которые есть в голове у разработчиков СУБД. Причем в PostgreSQL анализатор умнее и такие проблемы всплывают крайне редко.
Ну вот видите. Когда я выбирал СУБД, то я сделал верный выбор. Зачем мне субд, которая не имеет шардинга, если есть такой замечательный мускуль с шардингом.
А вы не задавали себе вопрос что вполне возможно все будет работать и без шардинга на другой СУБД.
Ваше мнение состоит главным образом в том, что для вашей задачи мускуль в некоторых ситуациях подтупливал и вы посчитали его убогим инструментом.
Проблема не в подтупливании, а в реальных проблемах СУБД. К примеру есть такая вполне реальная проблема в СУБД. В MySQL нельзя в update использовать туже таблицу во вложенном селекте добавленном в условиях. И там вот таких граблей раскидано не маленько.
У меня аналогичная ситуация была с постгресом (только мне его настроить было сложнее, до тупняков не дошло), но я не считаю, что он хуже мускуля.
Это не удивительно, поскольку он не хуже :]
Ваша проблема в том, что у вас развилась профессиональная слепота, которая приводит к игнорированию других инструментов, так как привыкли работать на этих.
Не надо выдумывать. Я тут достаточно примеров привел почему MySQL плохо. Да вот вам еще одна ссылочка
juick.com/Sectoid/1926975#11
Этот человек специализируется на СУБД. И работал в Percona так что MySQL он знает довольно хорошо.
Не так давно начал новый проект на монго и это для меня было очень трудно, так как нет привычной реляционности.
И это вполне понятно. Но я бы сначала крепко подумал зачем мне монго.
Просто он другой и под другие задачи и справляется с ними на ура.
Тут вы не правы и MySQL и PostgreSQL это РСУБД. И задачи они решают аналогичные.
Глава по настройке занимает 30 страницу + еще 2 главы про шардинг (около 50 страниц). Т.е. прочитав 80 страниц я могу настроить шардинг на мускуле и оптимизировать его под конкретный сервер. А есть ли такой подробный мануал для постгреса кроме этой презентации (которую кстати, если расписать подробно, то выйдет тоже около 100 страниц. там слайдов только около сотни)?
Кеш не имеет смысла только на данных, которые часто обновляются, так как мы только увеличим накладные расходы, а выигрыша не получим. Во всех остальных случаях кеш крайне рекомендуется. И если вы это не понимаете, то не вижу смысла с вами спорить. Если у вас и так все работает прекрасно и вы не закладываете масштабирование и развитие, то обходитесь без кеша.
Может действительно у меня простейшие задачи, которые не требует сильной изощренности, но мне достаточно прикинуть какие запросы я буду делать и соответствующим образом расставить индексы. Все. А писать непонятный запрос, надеясь на оптимизатор — я считаю неправильно и программистов, которые так делают уволил бы незамедлительно.
Ну чтобы не писать такой запрос стоит опять же почитать документацию ) Т.е. вы хотите писать говнокод и чтобы оптимизатор это правил? При таком запросе мускуль поступит разумно и очевидно: декартово произведение и выборка (стандарт SQL именно об это и говорит). А вот постгрес сделает неочевидные вещи, которые не всегда могут правильно отработать (например если будут коррелирующие запросы) и которые соответствуют стандарту не по сути, а лишь по результату. Вложенные селекты — опять же кривая архитектура. Всякий вложенный селект можно оптимизировать. Вы же не пишете сортировку массива в 100 миллионов элементов путем полного перебора ожидая что компилятор оптимизирует это дело и сделает бинарный поиск. Так почему вы ждете этого от СУБД? Всегда надо писать оптимально. Мускль пошел путем «я просто инструмент и делаю то, что ты мне сказал» (и я считаю это более правильным подходом), а постгрес сделали «я возьму любой твой говнокод и сделаю все что смогу, но не факт, что я тебя правильно пойму». Не знаю как в оракле, но в постгресе коррелирующие запросы почти никогда верно не оптимизируются (как и в мускуле).
В том и проблема, что сейчас каждый считает себя экспертом. Как вы считаете пилот самолета должен быть экспертом, чтобы перевозить пассажиров? Да! А летать на своем кукурузнике поливая урожай? нет. Такая ситуация и с мускулем. Если у тебя домашняя страничка, то ты можешь писать любой говнокод, вряд ли ты упрешься в высокие нагрузки. А если у тебя высоконагруженный сервис, то ты просто обязан знать нюансы используемых инструментов, иначе грош цена такому разработчику.
Я уже привел цифры по нагрузке на СУБД. Причем нагрузка постепенно увеличивается. Даже если предположить что один сервер постгреса выдержит 200 млн чтения и 50 млн записи и будет давать хорошую производительность(в чем я сильно сомневаюсь), то не факт. что через 2 года таких запросов не стане миллиард. И что вы предложите? Переписывать все с нуля? Купить новый более мощный сервер? Да, сейчас все шарды нагружены не полностью, но зато у меня нет головной боли.
А о причинах такого ограничения вы не задумывались? В той же самой книжке это подробно расписано. Как постгрес обходит это ограничение? Опять же скорее проблема архитектуры. Трудно представить реальный случай, где нужно сделать выборку из таблицы и тут же ее обновить. Вы не говорили о спицифике вашей задачи. У меня — это социальный сервис с кучей пользователей, картинок, аудиозаписей и сообщений. Может у вас действительно настолько специфичная ситуация и я не прав.
Каких примеров? То что вы написали странный запрос и ждете что каким-то чудом он оптимизируется? Почему вы используете постгрес, а не моного или коуч? Я могу кучу примеров привести что постгрес куда хуже чем эти субд, но на самом деле это не так. Просто я вычленю плюсы монго забыв о его минусах, а с постгресом сделаю обратную процедуру. А ссылка — всего лишь еще одно мнение ) Ну на этот раз она хоть куда-то ведет. А то ссылка на жж в которой где-то есть тесты — очень странно смотрелась.
Я и подумал. Причем не сам и очень долго. И выбрал. Вы хотите сказать посгрес лучше монго? Да у монго есть недостатки, но для моей задачи (хранение множества слабоструктурированных данных с высоким количеством операций чтения) идеально подходит. Лишнее подтверждение вашего игнорирования всего и вся.
Читайте внимательней. Я говорил что МОНГО другой и решает он другие задачи.
Кеш не имеет смысла только на данных, которые часто обновляются, так как мы только увеличим накладные расходы, а выигрыша не получим. Во всех остальных случаях кеш крайне рекомендуется. И если вы это не понимаете, то не вижу смысла с вами спорить. Если у вас и так все работает прекрасно и вы не закладываете масштабирование и развитие, то обходитесь без кеша.
Может действительно у меня простейшие задачи, которые не требует сильной изощренности, но мне достаточно прикинуть какие запросы я буду делать и соответствующим образом расставить индексы. Все. А писать непонятный запрос, надеясь на оптимизатор — я считаю неправильно и программистов, которые так делают уволил бы незамедлительно.
Ну чтобы не писать такой запрос стоит опять же почитать документацию ) Т.е. вы хотите писать говнокод и чтобы оптимизатор это правил? При таком запросе мускуль поступит разумно и очевидно: декартово произведение и выборка (стандарт SQL именно об это и говорит). А вот постгрес сделает неочевидные вещи, которые не всегда могут правильно отработать (например если будут коррелирующие запросы) и которые соответствуют стандарту не по сути, а лишь по результату. Вложенные селекты — опять же кривая архитектура. Всякий вложенный селект можно оптимизировать. Вы же не пишете сортировку массива в 100 миллионов элементов путем полного перебора ожидая что компилятор оптимизирует это дело и сделает бинарный поиск. Так почему вы ждете этого от СУБД? Всегда надо писать оптимально. Мускль пошел путем «я просто инструмент и делаю то, что ты мне сказал» (и я считаю это более правильным подходом), а постгрес сделали «я возьму любой твой говнокод и сделаю все что смогу, но не факт, что я тебя правильно пойму». Не знаю как в оракле, но в постгресе коррелирующие запросы почти никогда верно не оптимизируются (как и в мускуле).
В том и проблема, что сейчас каждый считает себя экспертом. Как вы считаете пилот самолета должен быть экспертом, чтобы перевозить пассажиров? Да! А летать на своем кукурузнике поливая урожай? нет. Такая ситуация и с мускулем. Если у тебя домашняя страничка, то ты можешь писать любой говнокод, вряд ли ты упрешься в высокие нагрузки. А если у тебя высоконагруженный сервис, то ты просто обязан знать нюансы используемых инструментов, иначе грош цена такому разработчику.
Я уже привел цифры по нагрузке на СУБД. Причем нагрузка постепенно увеличивается. Даже если предположить что один сервер постгреса выдержит 200 млн чтения и 50 млн записи и будет давать хорошую производительность(в чем я сильно сомневаюсь), то не факт. что через 2 года таких запросов не стане миллиард. И что вы предложите? Переписывать все с нуля? Купить новый более мощный сервер? Да, сейчас все шарды нагружены не полностью, но зато у меня нет головной боли.
А о причинах такого ограничения вы не задумывались? В той же самой книжке это подробно расписано. Как постгрес обходит это ограничение? Опять же скорее проблема архитектуры. Трудно представить реальный случай, где нужно сделать выборку из таблицы и тут же ее обновить. Вы не говорили о спицифике вашей задачи. У меня — это социальный сервис с кучей пользователей, картинок, аудиозаписей и сообщений. Может у вас действительно настолько специфичная ситуация и я не прав.
Каких примеров? То что вы написали странный запрос и ждете что каким-то чудом он оптимизируется? Почему вы используете постгрес, а не моного или коуч? Я могу кучу примеров привести что постгрес куда хуже чем эти субд, но на самом деле это не так. Просто я вычленю плюсы монго забыв о его минусах, а с постгресом сделаю обратную процедуру. А ссылка — всего лишь еще одно мнение ) Ну на этот раз она хоть куда-то ведет. А то ссылка на жж в которой где-то есть тесты — очень странно смотрелась.
Я и подумал. Причем не сам и очень долго. И выбрал. Вы хотите сказать посгрес лучше монго? Да у монго есть недостатки, но для моей задачи (хранение множества слабоструктурированных данных с высоким количеством операций чтения) идеально подходит. Лишнее подтверждение вашего игнорирования всего и вся.
Читайте внимательней. Я говорил что МОНГО другой и решает он другие задачи.
Глава по настройке занимает 30 страницу + еще 2 главы про шардинг (около 50 страниц). Т.е. прочитав 80 страниц я могу настроить шардинг на мускуле и оптимизировать его под конкретный сервер.
А есть ли такой подробный мануал для постгреса кроме этой презентации (которую кстати, если расписать подробно, то выйдет тоже около 100 страниц. там слайдов только около сотни)?
Вообще там из слайдов нужно 3 страницы. По шардингу есть отличная документация. Вот к примеру
michael.otacoo.com/postgresql-2/postgres-9-1-setup-a-synchronous-stand-by-server-in-5-minutes/
Ну чтобы не писать такой запрос стоит опять же почитать документацию ) Т.е. вы хотите писать говнокод и чтобы оптимизатор это правил?
Я хочу написать SQL запрос по стандарту, а не разбираться в особенностях СУБД. И часто это не говно код вовсе. В этом то и дело.
А писать непонятный запрос, надеясь на оптимизатор — я считаю неправильно и программистов, которые так делают уволил бы незамедлительно.
Есть такая вещь как стандарт на SQL. Объясните мне почему я должен знать всю специфику СУБД чтобы им пользоваться? В PostgreSQL мне это не надо и такое действо как по переставлять таблицы туда сюда делать надо довольно редко.
При таком запросе мускуль поступит разумно и очевидно: декартово произведение и выборка (стандарт SQL именно об это и говорит). А вот постгрес сделает неочевидные вещи, которые не всегда могут правильно отработать (например если будут коррелирующие запросы) и которые соответствуют стандарту не по сути, а лишь по результату.
PostgreSQL ничего того что вы описываете не делает :) Он максимум оптимизирует что за чем выбрать, чтобы отработать быстрее. А MySQL этого не сделает и в результате мне надо будет смотреть explain и переставлять самому.
Вложенные селекты — опять же кривая архитектура.
Смелое заявление. К тому же ничем не подтвержденное.
Всякий вложенный селект можно оптимизировать. Вы же не пишете сортировку массива в 100 миллионов элементов путем полного перебора ожидая что компилятор оптимизирует это дело и сделает бинарный поиск. Так почему вы ждете этого от СУБД?
Далеко не всякий. Вот у меня есть критерий выборки определенный. Туда попало 1 миллион записей. И оно медленно работает на MySQL. Мне я так понимаю надо создать временную таблицу и работать с ней?
Мускль пошел путем «я просто инструмент и делаю то, что ты мне сказал» (и я считаю это более правильным подходом), а постгрес сделали «я возьму любой твой говнокод и сделаю все что смогу, но не факт, что я тебя правильно пойму». Не знаю как в оракле, но в постгресе коррелирующие запросы почти никогда верно не оптимизируются (как и в мускуле).
Вот тут вы пишете полную ерунду. Если делаем все как я сказал то зачем вам SQL? SQL как раз делался для того чтобы можно было декларативно запросить данные и успокоится. И да и в PostgreSQL и Oracle оптимизация делается верно, если базу делали люди знающие теорию РСУБД не по наслышке. Дополнительно в Oracle еще можно добавлять hint который будет указывать какие индексы использовать.
А если у тебя высоконагруженный сервис, то ты просто обязан знать нюансы используемых инструментов, иначе грош цена такому разработчику.
Вопрос стоит когда тебе придется начинать это делать. В случае MySQL это начинается раньше чем в случае PostgreSQL
Я уже привел цифры по нагрузке на СУБД. Причем нагрузка постепенно увеличивается. Даже если предположить что один сервер постгреса выдержит 200 млн чтения и 50 млн записи и будет давать хорошую производительность(в чем я сильно сомневаюсь), то не факт. что через 2 года таких запросов не стане миллиард.
Где? Я вот что-то не вижу. 200 млн и 50 млн записи чего и куда?
И что вы предложите? Переписывать все с нуля? Купить новый более мощный сервер? Да, сейчас все шарды нагружены не полностью, но зато у меня нет головной боли.
Переехать на более мощный сервер. У вас это ситуация тоже случится и вы никуда от нее не денетесь.
А о причинах такого ограничения вы не задумывались? В той же самой книжке это подробно расписано.
А почему меня это должно волновать? Я взял инструмент и хочу его использовать. А вы меня отправляете читать книгу где написано почему у людей есть такое ограничение. Причем замечу в других СУБД его нет.
Как постгрес обходит это ограничение?
Молча. Он делает все в рамках одной транзакции. Сначала берет выборку, потом делает update. У MySQL я вижу только одну причину почему это так не работает. Потому что есть MyISAM. В случае InnoDB правда это тоже не работает, хотя он версионник.
У меня — это социальный сервис с кучей пользователей, картинок, аудиозаписей и сообщений.
А у меня АСР на 40k пользователей. Объем данных сравнивать будем? :]
То что вы написали странный запрос и ждете что каким-то чудом он оптимизируется?
Вы удивитесь, но запросы я пишу нормальные. Но периодически приходится подсматривать в explain. Вы вообще делали аналитические отчеты из СУБД какие либо?
Почему вы используете постгрес, а не моного или коуч?
Потому что это не РСУБД и если потребуется сделать там какую либо аналитику это будет более трудоемко чем в РСУБД. И в целом РСУБД больше подходит под мои задачи.
Я могу кучу примеров привести что постгрес куда хуже чем эти субд, но на самом деле это не так. Просто я вычленю плюсы монго забыв о его минусах, а с постгресом сделаю обратную процедуру.
Как минимум такое сравнение не корректно, потому что это разные классы СУБД. А вот сравнение PostgreSQL и MySQL вполне корректно. Потому что они принадлежат к одному и тому же классу СУБД и используются для аналогичных задач.
А ссылка — всего лишь еще одно мнение )
Это мнение человека который занимался разработкой MySQL, а сейчас занимается разработкой SciDB. Кстати да если вам нужен шардинг и хранение больших объемов данных имеет смысл посмотреть на нее.
Вы хотите сказать посгрес лучше монго?
Нет. Я сказал что я бы крепко подумал подходит ли MongoDB в данном случае и чем ее использование будет лучше чем использование РСУБД.
Лишнее подтверждение вашего игнорирования всего и вся.
Пока игнорированием фактов занимаетесь тут вы. Я вполне четко озвучил что плохо в MySQL. Повторюсь еще раз.
1. Слабый анализатор
2. Низкая производительность при высокой нагрузке и перекосе в запись.
3. Глобальные блокировки в процедурах.
4. Длинные транзакции могут привести к падению производительности и их лучше не использовать.
5. Более сложная настройка производительности чем у PostgreSQL.
6. Бедный язык хранимых процедур.
7. Хуже поведение на больших объемах данных.
Из плюсов MySQL могу выделить только
1. Большая известность
2. Может быть быстрее если мало операций записи
3. Наличие master-master репликации.
За ссылку спасибо, ознакомлюсь.
Есть такая штука, как реляционная алгебра. Очень помогает понять почему и как работают запросы. Так вот, стандарт основан на этой самой реляционной алгебре. И если вы почитаете как там выполняются джойны, а как выборка из всех таблиц, то вы поймете, что мускуль делает правильней и без самодеятельности, строго придерживаясь стандарта.
Опять же, вы кидаетесь фразой стандарт, стандарт, но кажется вы его совсем не читали ) Вот именно за это и уволил бы. То о чем вы говорите разрешено стандартом, но стандарт не говорит какой из методов более оптимален. А вот говорит упомянутая мной реляционная алгебра. И ее вы кажется тоже не знаете.
Вот тут совсем неправда про то, что мускуль не делает ) Не знаю, с какой версией вы работали последний раз, но мускуль вполне не плохо расставляет порядок выборок так, чтобы покрыть индексами наибольшее кол-во данных.
Про вложенные селекты — опять же читайте реляционная алгебра. Каждый вложенный селект вполне можно заменить объединением или исключением и на уровне алгебры это займет меньше операций. Отсюда я делаю вывод, что использование больше операций для одного и того же действия — кривая архитектура.
Вы не поверите, но в мускуль тоже можно указать какие индексы юзать ) И ерунду пишете вы. Вы же не ждете от С, что он сделает за вас всю работу.
Подтверждение тому, что у меня проблемы с мускулем возникнут раньше я не вижу. Пока все работает нормально. Если, не дай бог, у меня начнет что-то отваливаться, тормозить, то я вспомню вас, напишу и извинюсь )
Вы будете поражены, но данных в виде записей и в СУБД mysql ) или вы хотите увидеть дамп?
Видимо вы работаете не на себя и вам пофиг на затраты. Переехать на более мощный сервер стоит дороже в перспективе, чем добавить еще одну шарду. Что вы будете делать, если один сервер самый мощный из существующих на данное время перестанет справляться с нагрузками? Будете ждать пока прогресс шагнет еще дальше и купите еще более мощный сервер? После этого заявления я примерно понял масштаб вашего проекта, хоть это и ACP с 40к юзеров.
Это печально когда люди не изучая причин пользуются чем-то. Прочитайте все таки реляционную алгебру. Я, честно признаться, так и не освоил все нюансы этой науки, так как она довольно сложная, но понять многое мне это помогло.
Мне не интересно мериться с вами… кхм… объемами данных ) В конце концов я не говорю, что используемый вами инструмент — говно )
Да делал отчеты. И к чему вопрос? Но я знал, что если мне надо сделать выборку по низкоселективному полю, то это плохо и не жаловался, что мускуль меня не понял. Я просто искал как можно это оптимизировать.
Наконец вы поняли. «Больше подходит под мои задачи». Золотые слова. Почему произнесенные мной они до вас никак не доходят? Мускуль замечательно подходит под мои задачи, потому что когда я выбирал субд у него не было гемороев с репликациями и была адекватная возможность настроить шардинг. Сейчас все может и изменилось, но и мускуль уже тоже выпустил несколько мажоров.
В новом проекте, который еще только в зачаточном состоянии, я выбрал монго, так как шардинг реализованный там — на высоте. Почему вы считаете, что один человек, который был там и сям настолько крут, что я должен прислушиваться к его мнению безоговорочно, а толпа программистов, которые разработали замечательную СУБД (разработали, а не пользовались ей, как ваш чудо-мастер) — дебилы и ничего не смыслят.
1. Слабость анализатора вы так и не подтвердили. Писать плохие запросы и ждать чуда — это не слабый анализатор, а слабый программист.
2. К сожалению не знаю как мускуль поведет себя в таком случае. У меня больше чтения, чем записи.
3. Тут к сожалению не могу не согласиться, это минус. Но он меня не смущает, так как я не занимаюсь числодробилкой в процедурах и не перекладываю на них логику.
4. Аналогично 3му пункту. Не вижу смысла в дилнных транзакциях. Если они долгие, значит внутри выполняется кривой и неоптимизированный запрос.
5. Если у вас не получается настроить производительность мускуля, то это не значит что она такая сложная ) У меня например не получается стоять на руках, но я умею играть на гитаре. И дело не в том, что стоять на руках сложнее. Просто я не тренировался )
6. Вы уже привели пример его бености. Очень странные у вас потребности к языку. Я привел контраргументы.
7. Тесты? Вы так и не показали мне тесты! ) Я устал читать блог того парня (хотя довольно интересно было), но так и не нашел этих самых тестов.
По плюсам:
1. Задумайтесь почему она известней?
2. Может быть быстрее если и много операций? Просто надо уметь оптимизировать?
3. Мастер-мастер репликация под страхом смертной казни юзать не стану ) Может наличие фичи и плюс, но толку с нее не очень много.
Ладно, я вас понял ) Вы свято ненавидите мускуль потому что когда-то давно у вас с ним не сложилось: вы не смогли его настроить, оптимизатор вас подвел и вообще были сплошные проблемы. А с постгресом все сложилось идеально и вы теперь не видите в нем минусов. Постгрес решает ваши задачи и хорошо. Мускуль решает мои задачи. Вы считаете что мускуль говно — ладно, пусть будет так. Я буду дальше продолжать использовать это трудно настраиваемое, неоптимальное говно ) Мне надоел этот троллинг. Тем более у меня начались выходные, которые я не намерен тратить на споры с вами. Удачи в ваших начинаниях.
Есть такая штука, как реляционная алгебра. Очень помогает понять почему и как работают запросы. Так вот, стандарт основан на этой самой реляционной алгебре. И если вы почитаете как там выполняются джойны, а как выборка из всех таблиц, то вы поймете, что мускуль делает правильней и без самодеятельности, строго придерживаясь стандарта.
Опять же, вы кидаетесь фразой стандарт, стандарт, но кажется вы его совсем не читали ) Вот именно за это и уволил бы. То о чем вы говорите разрешено стандартом, но стандарт не говорит какой из методов более оптимален. А вот говорит упомянутая мной реляционная алгебра. И ее вы кажется тоже не знаете.
Вот тут совсем неправда про то, что мускуль не делает ) Не знаю, с какой версией вы работали последний раз, но мускуль вполне не плохо расставляет порядок выборок так, чтобы покрыть индексами наибольшее кол-во данных.
Про вложенные селекты — опять же читайте реляционная алгебра. Каждый вложенный селект вполне можно заменить объединением или исключением и на уровне алгебры это займет меньше операций. Отсюда я делаю вывод, что использование больше операций для одного и того же действия — кривая архитектура.
Вы не поверите, но в мускуль тоже можно указать какие индексы юзать ) И ерунду пишете вы. Вы же не ждете от С, что он сделает за вас всю работу.
Подтверждение тому, что у меня проблемы с мускулем возникнут раньше я не вижу. Пока все работает нормально. Если, не дай бог, у меня начнет что-то отваливаться, тормозить, то я вспомню вас, напишу и извинюсь )
Вы будете поражены, но данных в виде записей и в СУБД mysql ) или вы хотите увидеть дамп?
Видимо вы работаете не на себя и вам пофиг на затраты. Переехать на более мощный сервер стоит дороже в перспективе, чем добавить еще одну шарду. Что вы будете делать, если один сервер самый мощный из существующих на данное время перестанет справляться с нагрузками? Будете ждать пока прогресс шагнет еще дальше и купите еще более мощный сервер? После этого заявления я примерно понял масштаб вашего проекта, хоть это и ACP с 40к юзеров.
Это печально когда люди не изучая причин пользуются чем-то. Прочитайте все таки реляционную алгебру. Я, честно признаться, так и не освоил все нюансы этой науки, так как она довольно сложная, но понять многое мне это помогло.
Мне не интересно мериться с вами… кхм… объемами данных ) В конце концов я не говорю, что используемый вами инструмент — говно )
Да делал отчеты. И к чему вопрос? Но я знал, что если мне надо сделать выборку по низкоселективному полю, то это плохо и не жаловался, что мускуль меня не понял. Я просто искал как можно это оптимизировать.
Наконец вы поняли. «Больше подходит под мои задачи». Золотые слова. Почему произнесенные мной они до вас никак не доходят? Мускуль замечательно подходит под мои задачи, потому что когда я выбирал субд у него не было гемороев с репликациями и была адекватная возможность настроить шардинг. Сейчас все может и изменилось, но и мускуль уже тоже выпустил несколько мажоров.
В новом проекте, который еще только в зачаточном состоянии, я выбрал монго, так как шардинг реализованный там — на высоте. Почему вы считаете, что один человек, который был там и сям настолько крут, что я должен прислушиваться к его мнению безоговорочно, а толпа программистов, которые разработали замечательную СУБД (разработали, а не пользовались ей, как ваш чудо-мастер) — дебилы и ничего не смыслят.
1. Слабость анализатора вы так и не подтвердили. Писать плохие запросы и ждать чуда — это не слабый анализатор, а слабый программист.
2. К сожалению не знаю как мускуль поведет себя в таком случае. У меня больше чтения, чем записи.
3. Тут к сожалению не могу не согласиться, это минус. Но он меня не смущает, так как я не занимаюсь числодробилкой в процедурах и не перекладываю на них логику.
4. Аналогично 3му пункту. Не вижу смысла в дилнных транзакциях. Если они долгие, значит внутри выполняется кривой и неоптимизированный запрос.
5. Если у вас не получается настроить производительность мускуля, то это не значит что она такая сложная ) У меня например не получается стоять на руках, но я умею играть на гитаре. И дело не в том, что стоять на руках сложнее. Просто я не тренировался )
6. Вы уже привели пример его бености. Очень странные у вас потребности к языку. Я привел контраргументы.
7. Тесты? Вы так и не показали мне тесты! ) Я устал читать блог того парня (хотя довольно интересно было), но так и не нашел этих самых тестов.
По плюсам:
1. Задумайтесь почему она известней?
2. Может быть быстрее если и много операций? Просто надо уметь оптимизировать?
3. Мастер-мастер репликация под страхом смертной казни юзать не стану ) Может наличие фичи и плюс, но толку с нее не очень много.
Ладно, я вас понял ) Вы свято ненавидите мускуль потому что когда-то давно у вас с ним не сложилось: вы не смогли его настроить, оптимизатор вас подвел и вообще были сплошные проблемы. А с постгресом все сложилось идеально и вы теперь не видите в нем минусов. Постгрес решает ваши задачи и хорошо. Мускуль решает мои задачи. Вы считаете что мускуль говно — ладно, пусть будет так. Я буду дальше продолжать использовать это трудно настраиваемое, неоптимальное говно ) Мне надоел этот троллинг. Тем более у меня начались выходные, которые я не намерен тратить на споры с вами. Удачи в ваших начинаниях.
И если вы почитаете как там выполняются джойны, а как выборка из всех таблиц, то вы поймете, что мускуль делает правильней и без
самодеятельности, строго придерживаясь стандарта.
Эм в каком стандарте прописано как реализовывать join на уровне СУБД? Мне правда интересно. Можете еще ссылочку привести.
То о чем вы говорите разрешено стандартом, но стандарт не говорит какой из методов более оптимален.
Вот это должна делать СУБД и в случае MySQL она этого не делает по вашим же словам.
И ее вы кажется тоже не знаете.
Конечно, конечно. Кто-то тут помнится мне говорил про то что я перехожу на личности, но больше это про вас можно сказать.
Не знаю, с какой версией вы работали последний раз, но мускуль вполне не плохо расставляет порядок выборок так, чтобы покрыть индексами наибольшее кол-во данных.
В случае индексов да. В случае вложенных селектов далеко не всегда.
Вы не поверите, но в мускуль тоже можно указать какие индексы юзать )
Раньше не было. Сейчас да посмотрел есть. До Oracle не дотянут но покатит.
И ерунду пишете вы. Вы же не ждете от С, что он сделает за вас всю работу.
Например в Java я ожидаю, что виртуальная машина за меня освободит память.
Про вложенные селекты — опять же читайте реляционная алгебра. Каждый вложенный селект вполне можно заменить объединением или исключением и на уровне алгебры это займет меньше операций.
Ага и получите в два раза больше кода.
Отсюда я делаю вывод, что использование больше операций для одного и того же действия — кривая архитектура.
Не правильно вывод делаете. Часто проще и быстрее сделать вложенные select.
Подтверждение тому, что у меня проблемы с мускулем возникнут раньше я не вижу.
Интересно как вы его увидите если у вас нет такой же базы данных в PostgreSQL. А я между прочим приводил подтверждение. Конкретно про zabbix. Объем базы только увеличивается.
Вы будете поражены, но данных в виде записей и в СУБД mysql ) или вы хотите увидеть дамп?
Так это мало. У меня в месяц под несколько сотен миллонов в таблицу набегало. На таких объемах как у вас, данные можно и в MySQL держать. У вас просто еще не было большой БД. :]
Видимо вы работаете не на себя и вам пофиг на затраты. Переехать на более мощный сервер стоит дороже в перспективе, чем добавить еще одну шарду.
Вообще прежде чем покупать сервер я оптимизирую все что можно. И часто проблема именно в записи. В этом случае шарды master-slave помогут мало.
Это печально когда люди не изучая причин пользуются чем-то. Прочитайте все таки реляционную алгебру. Я, честно признаться, так и не освоил все нюансы
С чего вы взяли, что я ее не читал? Я как раз читал. А еще я читал как работают СУБД и знаю как делать ER-диаграммы. И да ничего там сложного нет. Почитайте лекции Кузнецова citforum.ru/database/osbd/contents.shtml
Там очень подробно и толково все описано.
Да делал отчеты. И к чему вопрос? Но я знал, что если мне надо сделать выборку по низкоселективному полю, то это плохо и не жаловался, что мускуль меня не понял. Я просто искал как можно это оптимизировать.
Когда пишешь запрос к отчету который занимает 4 страницы сидеть и вылизывать каждую мелочь не очень то и хочется.
Почему произнесенные мной они до вас никак не доходят?
Потому что мы сравниваем две РСУБД, а не то что вам подходит под задачу или не подходит под задачу. В случае MySQL и PostgreSQL их можно заменить друг другом.
В новом проекте, который еще только в зачаточном состоянии, я выбрал монго, так как шардинг реализованный там — на высоте.
Только из-за шардинга? Соболезную.
1. Слабость анализатора вы так и не подтвердили. Писать плохие запросы и ждать чуда — это не слабый анализатор, а слабый программист.
В смысле не подтвердил? Вам сделать БД и показать где он лажает? Знаете интернет большой. Поищите сравнения. Это не только мое мнение.
2. К сожалению не знаю как мускуль поведет себя в таком случае. У меня больше чтения, чем записи.
Можете синтетическую ситуацию воспроизвести сделайте 30-40 потоков и пишите в две-три таблицы разом. Сразу скажу в случае MyISAM можно сразу закапывать. В случае InnoDB ситуация получше.
3. Тут к сожалению не могу не согласиться, это минус. Но он меня не смущает, так как я не занимаюсь числодробилкой в процедурах и не перекладываю на них логику.
Из-за этого многие вещи там просто не сделать увы.
4. Аналогично 3му пункту. Не вижу смысла в дилнных транзакциях. Если они долгие, значит внутри выполняется кривой и неоптимизированный запрос.
Это у вас просто данных мало. Будет много данных с массированными операциями записи и обновления поймете зачем.
5. Если у вас не получается настроить производительность мускуля, то это не значит что она такая сложная )
Почему не получается. Получается. Просто этот процесс менее логичный чем в PostgreSQL и разделен на две части. Одна касается сервера, вторая движка.
6. Вы уже привели пример его бедности. Очень странные у вас потребности к языку. Я привел контраргументы.
Отсутствие raise. Отсутствие такой фичи как returning. Плюс отсутствие документации по этим самым процедурам. Когда я в последний раз читал там было написо ну вот как-то так.
7. Тесты? Вы так и не показали мне тесты! ) Я устал читать блог того парня (хотя довольно интересно было), но так и не нашел этих самых тестов.
Видимо тот тест он публиковал не в ЖЖ. Вот старый тест tweakers.net/reviews/657/6 Из нового найти не могу.
1. Задумайтесь почему она известней?
По той же причине почему PHP известнее Java.
2. Может быть быстрее если и много операций? Просто надо уметь оптимизировать?
Увы нет. Если у вас будет много записи, то у вас будут проблемы с производительностью. Да если вы еще при этом ACID не перенастроите в InnoDB то будут очень большие проблемы.
3. Мастер-мастер репликация под страхом смертной казни юзать не стану ) Может наличие фичи и плюс, но толку с нее не очень много.
Я настраивал в одном месте. Ну работает. Но там и записи е сильно много.
Вы свято ненавидите мускуль потому что когда-то давно у вас с ним не сложилось: вы не смогли его настроить, оптимизатор вас подвел и вообще были сплошные проблемы.
Я где-то говорю что я ненавижу MySQL? Я говорю что этот софт хуже PostgreSQL. Почему я уже рассказал не раз. Опять же судя по тому что вы пишете MySQL у вас первая РСУБД. У меня же первой РСУБД была Firebird. Которая по возможностям ближе к PostgreSQL. В результате когда приходишь и смотришь на MySQL то ощущение что ты пересел из BMW в жигули. Да можно сделать чтобы жигули ездили и возили куда надо. Но комфорт не тот.
А с постгресом все сложилось идеально и вы теперь не видите в нем минусов.
У PostgreSQL своих минусов тоже хватает. Это придурочная фича под названием наследование. Отсутствие хинтов. Этот механизм разработчики просто отказались добавлять в СУБД. Пока не очень удачный механизм партицирования.
Это было в сутки ;) Это вы еще не работали с большой базой ;)
Это было в сутки ;) Это вы еще не работали с большой базой ;)
В сутки чего? Вот пока из написанного непонятно ровным словом ничего. Так что говорить кто тут работал или не работал с большой базой это вопрос относительный.
Ладно, вы уже перешли на троллинг. я пару комментов назад говорил: 200 млн операций чтения в сутки и около 50 млн. операций записи в сутки. Перечитайте, если хотите.
ну вообще было вот такое написано
Куда чего не было указано. По этому и спрашиваю.
Даже если предположить что один сервер постгреса выдержит 200 млн чтения и 50 млн записи
Куда чего не было указано. По этому и спрашиваю.
Читайте внимательней. Выше было: «4.5 миллиона пользователей в базе, 200 миллионов чтений и около 50 млн. записи ежедневно. „
В следующий раз читайте внимательней. Я говорил, что это ежедневная нагрузка
И почитайте что такое шардинг. Шардинг когда данные не реплицируются а разносятся на несколько серверов
>> Ведь не зря его использует такое кол-во людей.
>Как правило эти люди или не видели других СУБД или ее выбрали за них.
они просто ни чего не знали кроме Денвера и ЛАМП
>Как правило эти люди или не видели других СУБД или ее выбрали за них.
они просто ни чего не знали кроме Денвера и ЛАМП
>Поэтому дело не в инструменте, а в руках, его использующих.
+1
и это относится не только к мускулю, но и к РНР, С и прочим ср-вам разработки.
+1
и это относится не только к мускулю, но и к РНР, С и прочим ср-вам разработки.
> Если сравнить постгрес и мускль, то можно заметить, что и там, и там есть как плюсы, так и минусы
это ключевое слово: и там и там…
как-то я был на Битве Титанов MySQL & PgSQL… было очень занимательно…
а я скажу Вам: оба инструмента хороши, у каждого свои плюсы.
это ключевое слово: и там и там…
как-то я был на Битве Титанов MySQL & PgSQL… было очень занимательно…
а я скажу Вам: оба инструмента хороши, у каждого свои плюсы.
Наркоманы!!! и это мне подтвердили сами разработчики MySQL.
А может осветить ещё вопроса:
1. как обстоят дела с передачей массивов в stored procedure?
2. как обстоит работа с иерархией таблиц?
1. как обстоят дела с передачей массивов в stored procedure?
2. как обстоит работа с иерархией таблиц?
3. Материализованные представления с фаст рефреш он коммит? Констрейнты на них?
4. ДБ линки, распределенные транзакции, гетерогенные сервисы?
5. Virtual columns и констрейнты на них? Битмап индексы?
6. RAC или аналог? Горячий стендбай открытый на чтение (аналог Active Data Guard)? Логический стендбай?
7. Point-in-time recovery? Flashback queries? Флешбек вообще?
8. Кластеры?
9. Развитая система dbms_ пекеджей на все случаи жизни?
10. Аналитика?
Не холивора ради: на самом деле таких обзоров куча — интересно было бы собрать все в одном месте :)
4. ДБ линки, распределенные транзакции, гетерогенные сервисы?
5. Virtual columns и констрейнты на них? Битмап индексы?
6. RAC или аналог? Горячий стендбай открытый на чтение (аналог Active Data Guard)? Логический стендбай?
7. Point-in-time recovery? Flashback queries? Флешбек вообще?
8. Кластеры?
9. Развитая система dbms_ пекеджей на все случаи жизни?
10. Аналитика?
Не холивора ради: на самом деле таких обзоров куча — интересно было бы собрать все в одном месте :)
В догонку — лично мое имхо — намного интереснее было бы посмотреть глазами ораклиста в сторону постргес на предмет «чего такого есть там, чего так не хватает / не так удобно тут». Собственно часть Pros требует развития.
3. нет
4. нет
5. нет
6. Горячий стендбай есть начиная с 9.1 версии.
7. нет
8. нет
9. лол што?
10. Аналитика имеется. Как настраивать не знаю, но есть :)
4. нет
5. нет
6. Горячий стендбай есть начиная с 9.1 версии.
7. нет
8. нет
9. лол што?
10. Аналитика имеется. Как настраивать не знаю, но есть :)
Был немного удивлён реализацией VIEW через RULES. Век живи — век учись.
> Убогое партиционирование через наследование таблиц и триггеры (или правила).
Я как раз использую партиционирование в PostgreSQL 9.1. Хотелось бы узнать, чем оно лучше в Oracle? Удобство имплементации или есть данные по эффективности работы?
Я как раз использую партиционирование в PostgreSQL 9.1. Хотелось бы узнать, чем оно лучше в Oracle? Удобство имплементации или есть данные по эффективности работы?
Чем удобней секционирование в Oracle:
1.1. Меньшее количество операций для создания, настройки и переделок. Больше вариантов секционирования (линк1, link2). Тут и способы как разбить таблицу и вложенные секции и еще много чего. В 11g сделали автоматическое создание новых секций.
1.2. Для ПО — это одна таблица, всю внутреннюю кухню БД ведет сама (посмотреть что внутри можно через системные словари и вьюшки).
По скорости:
2.1. Для вставки не нужен «for each row» триггер, вы вставляете данные, а БД сама понимает куда их надо заносить. Тут можно выкрутится через RULE, но согласитесь «удобство» работы страдает.
2.2. Oracle нормально и без заметных просадок работает тысячами партиций, в доке по Postgres (есть интересная фраза «Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.»)
2.3. Спорный момент, но в Oracle можно сделать глобальный индекс по всем секциям, что в некоторых случаях может дать прибавку по скорости.
1.1. Меньшее количество операций для создания, настройки и переделок. Больше вариантов секционирования (линк1, link2). Тут и способы как разбить таблицу и вложенные секции и еще много чего. В 11g сделали автоматическое создание новых секций.
1.2. Для ПО — это одна таблица, всю внутреннюю кухню БД ведет сама (посмотреть что внутри можно через системные словари и вьюшки).
По скорости:
2.1. Для вставки не нужен «for each row» триггер, вы вставляете данные, а БД сама понимает куда их надо заносить. Тут можно выкрутится через RULE, но согласитесь «удобство» работы страдает.
2.2. Oracle нормально и без заметных просадок работает тысячами партиций, в доке по Postgres (есть интересная фраза «Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.»)
2.3. Спорный момент, но в Oracle можно сделать глобальный индекс по всем секциям, что в некоторых случаях может дать прибавку по скорости.
2.2. — согласен, существенно.
1.2 и 2.1 — У меня работает через автоматическое создание правил, само создается раз в сутки. Ну и для приложения выглядит как одна таблица.
Зато я наблюдаю временную блокировоку при создании и удалении новой партиции на рабочей базе при массе insert/update, а это негативно сказывается на работе приложения в целом.:((
1.2 и 2.1 — У меня работает через автоматическое создание правил, само создается раз в сутки. Ну и для приложения выглядит как одна таблица.
Зато я наблюдаю временную блокировоку при создании и удалении новой партиции на рабочей базе при массе insert/update, а это негативно сказывается на работе приложения в целом.:((
pgAgent, разве не про job'ы внутри? Хотя оно странное, мы покрутили-посмотрели, и не стали использовать :)
Конечно, 47 килобаксов — это 47 килобаксов, но справедливости ради:
В Oracle тоже есть три варианта: restrict (по умолчанию), cascade и set null
В Oracle есть такие штуки как FGA (fine grain audit) и RLS (row-level security). Может, не совсем то, но похоже.
constraint constname references tablename on delete cascade удалит связанные записи при удалении родительской.
В Oracle тоже есть три варианта: restrict (по умолчанию), cascade и set null
Замечательная, но потенциально опасная (как триггеры) система правил (RULES) позволяющая подменять текст запроса отправляемый серверу. Через неё, например, реализованы VIEW.
В Oracle есть такие штуки как FGA (fine grain audit) и RLS (row-level security). Может, не совсем то, но похоже.
НЛО прилетело и опубликовало эту надпись здесь
Есть, гуглится в 10 секунд — www.pgadmin.org/docs/1.8/debugger.html
Уважаемый вы все это конечно хорошо написали, но ответьте пож-ста на вопрос: зачем в БД нужно засовывать логику которую можно реализовать программно? БД предназначена для хранения данных а не для обработки их.
Но вопрос можно поставить и по-другому — зачем писать дополнительный программный код для вещей которые проще реализуются в бд?
К сожалению я знаю очень мало вещей, которые проще реализовать и поддерживать в БД.
НЛО прилетело и опубликовало эту надпись здесь
С первичной реализацией может и помогут, а вот с поддержкой… Всё же привычным при работе с обычным кодом приёмам инструментарий работы с СУБД не обучен. Популярные РСУБД нацелены на исполнение команд, изменяющих логику, а не на приём этой логики в декларативной форме как традиционные трансляторы ЯП и инструментарий толком не помогает.
Если вы имеете ввиду, что при наличие спеца по базам облегчает поддержку логики, написанной в ней, то вы конечно правы, но…
Поддержка хранимок в БД осложняется крайне примитивными инструментами работы с ней. Например ни один из использованных мной инструментов для общения с ораклом(тоад, plsql developer, плагины в идее, родная оракловская приблуда) по простоте и безопасности рефакторинга и навигации по коду и близко не стоят в сравнении с IDE для таких языков, как PHP, Java и д.р. Я уж не говорю про не самый дружелюбный синтаксис БД языков.
Если же вы имели в виду, что специалисты смогут привести мне примеры которые проще реализуются в бд, то я не отрицаю возможности таковых, просто по моему опыту их не много. Как правило, логика в базе появляется не потому что так проще, а потому, что так дешевле или быстрее. Это критичные к быстродействию или очень большие по объемам запросы. Когда вытаскивать это из базы и обрабатывать снаружи либо слишком долго, либо требует неоправданно много ресурсов.
НЛО прилетело и опубликовало эту надпись здесь
Эти принципы говорят о том, что в обозримом будущем инструментарий разработки SQL так и останется довольно примитивным и недружелюбным.
P.S. Пролистал (читал её сразу) статью — там ничего о хранимых процедурах/функциях/триггерах, которые обычно подразумевают под логикой в СУБД. Основная проблема разработки основной нереляционной логики в СУБД в том, по-моему, что разработчик(представляющая его система CI/CD) вынужден управлять логикой через императивные команды типа CREATE FUNCTION Abc, а не просто иметь где-то файлик abc.sql с FUNCTION Abc, который можно скормить СУБД, и она сама приведёт внутреннее состояние в нужный вид. То есть для удобной разработки прежде всего нужен способ изменения логики процедур и т. п. без отдачи императивных команд на создание/изменение (а где-то изменить нельзя, а только удалить и создать заново) функций с такой-то логикой, а указанием на место (желательно на диске) где хранится декларативное описание функций.
Парадокс: обычно SQL называют декларативным языком, хотя всё происходит через явные команды, а в языках, которые традиционно считаются императивными, основа — декларативное описание функций и классов, а отдача команд в коде верхнего уровня может быть вообще не предусмотрена.
НЛО прилетело и опубликовало эту надпись здесь
Подразумевание не может быть ошибочным. Я могу ошибаться, что люди говоря о сложности реализации бизнес-логики средствами СУБД подразумевают, прежде всего, реализацию её на процедурах, функциях, триггерах и т. д., но когда я говорю о сложности этого, то я точно знаю, что подразумеваю.
Большинство реальных бизнес-процессов, изменяющих состояние приложения в целом, плохо ложатся на реляционную модель и в основном, говоря о их реализации средствами СУБД, имеют в виду старое доброе процедурное программирование (иногда ООП), иногда событийное, но не попытки реализовать сложную логику через SELECT запросы.
В чем именно ошибка?
В том, что вы под логикой в БД имеете вещи не относящиеся к хранимкам, пакетам, функциям и триггерам?
В таком случае давайте тогда определимся с системой понятий. Дайте определение вашей логики в БД.
Наличие оснований для указанных мной недостатков, не означает что этих недостатков нет.
Я не отказываю БД серверам в плюсах, но простота поддержки написанной в ней логики к ним не относится.
Как минимум, чтобы избежать передачи кучи данных между процессами/хостами. Вы же не грузите все данные в приложение через только SELECT * FROM table, фильтруя их только там, даже без WHERE?
Вот это — вброс так вброс :)
Нет механизма джобов на стороне сервера, все процессы должны быть инициированы снаружи базы (например, cron).
Вообще более близкое подобие есть pgagent
Мое личное мнение, что Постгра прекрасная база данных для не Энтерпрайз проектов, хотя и данная роль посгры под вопросом после выхода Oracle XE (бесплатная версия базы данных Oracle, имеет ряд ограничений).
Но для крупных Энтерпрайз решений Postgress неприменим по причине своей незрелости, для примера могу привести необходимость обращения базы к самой себе по средствам DB Link для реализации автономной транзакции, лично мне кажется дикостью!!!
Но для крупных Энтерпрайз решений Postgress неприменим по причине своей незрелости, для примера могу привести необходимость обращения базы к самой себе по средствам DB Link для реализации автономной транзакции, лично мне кажется дикостью!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL vs Oracle