Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 17   вперед  Ctrl
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
H5N1
факт в том что ты туп и упорот,

Да нет же, только ты. Как ты всё никак не запомнишь... а да, ты же туп и упорот, что же это я. ;)

H5N1
а причину uber детально изложил вот тут https://eng.uber.com/mysql-migration/

Uber может "излагать" всё, что ему нравится (и причины "изложения" тебе уже были названы... но ты не осилил, видно).
От этого оно становится правдой не больше, чем наглое вранье про PostgreSQL в "сравнительных" документах Oracle.

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

Это ты так говоришь. Ссылку покажи, чтобы было написано "претензий к архитектуре Oracle у нас не было! Искренне Ваши, программисты Yandex". ;)

H5N1
прослыть дебилом, который не слышал о причинах миграции Uber не мой метод. вот совсем.

Да ты что? ;) Поздравляю, ты уже прослыл.
Сходил бы ты технические обсуждения их миграции почитал, что ли...
25 дек 18, 22:40    [21773420]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
У них поддержка уровня оказания консультаций и замены дба, а не оперативные фиксы самого ванильного Postgres. Те, кто готовы делать фиксы, делают форки.

Охо-хо. :( Ну а это Вы с чего взяли? Не пользовались, но осуждаете?

Eleanor
Тот же Постгрес Про ответил, что фиксы в первую очередь делает в своем ПО, поэтому ставьте Про версию, а не ванильную. В ванильной они проконсультируют, помогут с производительностью, помониторят и всё.

Так это позиция конкретно Postgres Pro (даже если это правда, я после Вашей болтовни про "пройденные" Oracle тесты TPC уже как-то не очень верю), при чём тут прочие-то? Не нравится их поддержка --- найдёте другую, большое дело.

Eleanor
В обеих ссылках, что приводила, были дополнительные ссылки на результаты тестирования Postgres и GreenPlum.

При чём тут GreenPlum? Это очень далеко (в сторону) ушедший fork, с сильно отличающейся архитектурой, назначением и совсем другими разработчиками.

Далее, читаем (про TPC-H):
The results have generally been disappointing, for reasons that aren't necessarily relevant in the real world.
PostgreSQL is missing some of the things needed to do well on this benchmark, whereas proprietary database vendors are so focused on it they will "game" TPC-H runs (add optimizations specifically aimed at it) to make absolutely sure they do well.

Вы думаете, последнее предложение --- это ложь?
Ну так докажите это, "макните PostgreSQL лицом в грязь", чего же Вы ждёте?
25 дек 18, 22:53    [21773432]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Это ты так говоришь. Ссылку покажи, чтобы было написано "претензий к архитектуре Oracle у нас не было! Искренне Ваши, программисты Yandex". ;)

А легко.

Oracle — прекрасная база данных, но и с ней были проблемы. Например, выкладка PL/SQL кода — это боль, потому что есть library cache. Если база под нагрузкой, то нельзя просто взять и обновить код функции, который сейчас используется какими-то сессиями.

Остальные проблемы связаны не столько с Oracle, сколько с тем подходом, который мы использовали.


А теперь читаем в этой же статье на русском языке некоторые интересные подробности.

"...В октябре 2012 года, больше 4 лет назад, было принято решение о том, что мы должны избавиться от Oracle. Не звучало слов PostgreSQL, не звучало каких-либо технических подробностей — это было чисто политическое решение: избавиться, срок в 3 года..."

Тут даже не деньги жалко, тут политика. Понимаю, сочувствую.

"...Поскольку Oracle лицензируется по процессорным ядрам, мы были вынуждены масштабироваться вертикально. На одно процессорное ядро мы напихивали много памяти, много SSD-дисков. Было небольшое количество баз с небольшим количеством процессорных ядер, но с огромными массивами памяти и дисков. У нас всегда была строго одна реплика для отказоустойчивости, потому что все последующие — это деньги.

В PostgreSQL мы поменяли подход. Мы стали делать базы поменьше и по две реплики в каждом шарде. Это позволило нам заворачивать читающие нагрузки на реплики. То есть в Oracle всё обслуживалось с мастера, а в PostgreSQL — три машины вместо двух поменьше, и чтение заворачиваем в PostgreSQL. В случае с Oracle мы масштабировались вертикально, в случае с PostgreSQL масштабируемся горизонтально..."

То есть переехать не получилось, даже с учетом того, что стали вытягивать железом - пришлось базы резать на более мелкие. А денег на реплики Oracle изначально было жалко. Понимаю, сочувствую (с).

"...В случае с PostgreSQL мы решили перейти к новой схеме, когда у нас идентификаторы уникальны в пределах одного пользователя. Если раньше уникальным был mid идентификатор письма, то теперь уникальной является пара uid mid..."

Еще и код пришлось вдумчиво менять. Не получилось логику AS IS перенести, хотя PotgreSQL Pro бьет себя пяткой в грудь, что в рамках импортозамещения логика практически на 99% переносима. Понимаю, сочувствую (с).

"...В PostgreSQL всё хорошо с массивами, композитами. Мы сделали денормализацию части данных..."

Жизнь заставила подумать и сделать кошерно то, что должно было быть сделано изначально правильно. Понимаю, сочувствую (с).

"...Поскольку нет undo, цена ошибки стала сильно выше..."

Жизнь боль, нужно 7 раз отмеривать, 1 раз отрезать, как хороший ребе при обрезании. Понимаю, сочувствую (с).

"...Это список тредов в комьюнити с проблемами, которые мы самостоятельно решить не смогли.

Problem with ExclusiveLock on inserts
Checkpoint distribution
ExclusiveLock on extension of relation with huge shared_buffers
Hanging startup process on the replica after vacuuming on master
Replication slots and isolation levels
Segfault in BackendIdGetTransactions

То есть мы пошли в комьюнити, и нам помогли..."

А могли бы и не помочь. Как здорово, что у Яндекса такие друзья хорошие из комьюнити. Но у других таких друзей меньше. И помощи иногда ждать не приходится. Понимаю, сочувствую (с).

"...Сюрприз. Мы столкнулись с проблемой с бэкапами. У нас recovery window 7 дней, то есть мы должны иметь возможность восстановиться на любой момент в прошлом за последние 7 дней. В Oracle размер места под все бэкапы и архивлоги был равен примерно размеру базы. База 15 терабайт — и её бэкап за 7 дней занимает 15 терабайт.

В PostgreSQL мы используем barman, и в нём под бэкапы нужно места минимум в 5 раз больше, чем размер базы. Потому что WAL сжимаются, а бэкапы нет..."

Сюрприз, что стоимость обвязки оказывается у "бесплатных" продуктов сильно больше? Ну что же, нужно было документацию читать ДО начала перехода на "бесплатное" решение, а не ПОСЛЕ. Впрочем, ничего нового (с).

"...Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята..."

Ай-яй-яй, как нехорошо. Жадными быть плохо. Но ведь в любой компании, не только в Яндексе, есть специалисты на C++, который способны запатчить барман? Или не у всех такие есть? Понимаю, сочувствую (с).

"...Ещё мы очень хотим нормальную работу с диском. В плане дискового I/O PostgreSQL сильно проигрывает Oracle..."

Какая неожиданность. Оказывается, двойное кэширование и чтение маленькими порциями не очень хорошие вещи. Понимаю, сочувствую (с).

"...Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle. Пока у нас не было крупных факапов..."

Я представил разговор - "мы готовы переехать на сервере с оракла на бесплатный postgresql, но нужно купить еще 2 таких сервера. А так все бесплатно. Только купить и все. А так - все бесплатно". Слово "пока" во фразе насчет крупных факапов тоже делает мне смешно. Впрочем, ничего нового (с).
25 дек 18, 23:12    [21773443]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 2354
PgSQLanonymous3
при чём тут прочие-то? Не нравится их поддержка --- найдёте другую, большое дело.

Ближе к делу: с кем у вас сейчас договор о поддержке ванильного Postgres, сколько вы им платите, время отклика на инцидент? Что к примеру они вам пофиксили в Postgres и в какой срок.
Какие еще компании рассмотрели в качестве альтернативы во время выбора саппортера.
26 дек 18, 00:25    [21773478]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Ближе к делу: с кем у вас сейчас договор о поддержке ванильного Postgres, сколько вы им платите, время отклика на инцидент?

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

Eleanor
Что к примеру они вам пофиксили в Postgres и в какой срок.

Это ещё зачем? Это же не Oracle...
В отличие от (если я правильно понял Ваш посыл) Oracle, PostgreSQL на ходу не разваливается, и большинство пользователей с багами не встречаются годами, а то и вовсе никогда.
26 дек 18, 09:55    [21773600]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58933
Блог
Andy_OLAP
Например, выкладка PL/SQL кода — это боль, потому что есть library cache. Если база под нагрузкой, то нельзя просто взять и обновить код функции, который сейчас используется какими-то сессиями.

Начиная с Oracle 11g2 (cентябрь 2009-го года) уже неактуально. Существует такая фича как editions, которая вот именно для подобных случаев типа яндекс.почты подходит просто идеально.
26 дек 18, 10:31    [21773642]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
А легко.

Я же не Вас спрашивал, не так ли?
Меня просто достала генерация H5N1 бреда в промышленных масштабах вместо приведения хоть какой-то аргументации.
Ну ладно, раз уж Вы всё это написали...

Andy_OLAP
Oracle — прекрасная база данных, но и с ней были проблемы. Например, выкладка PL/SQL кода — это боль, потому что есть library cache. Если база под нагрузкой, то нельзя просто взять и обновить код функции, который сейчас используется какими-то сессиями.

Остальные проблемы связаны не столько с Oracle, сколько с тем подходом, который мы использовали.


А теперь читаем в этой же статье на русском языке некоторые интересные подробности.

"...В октябре 2012 года, больше 4 лет назад, было принято решение о том, что мы должны избавиться от Oracle. Не звучало слов PostgreSQL, не звучало каких-либо технических подробностей — это было чисто политическое решение: избавиться, срок в 3 года..."

Тут даже не деньги жалко, тут политика. Понимаю, сочувствую.


Абзацем выше там чётко написано: "Но главная причина перехода — это деньги. Oracle стоит дорого."
Пропустили? "Понимаю, сочувствую."

Andy_OLAP
"...Поскольку Oracle лицензируется по процессорным ядрам, мы были вынуждены масштабироваться вертикально. На одно процессорное ядро мы напихивали много памяти, много SSD-дисков. Было небольшое количество баз с небольшим количеством процессорных ядер, но с огромными массивами памяти и дисков. У нас всегда была строго одна реплика для отказоустойчивости, потому что все последующие — это деньги.

В PostgreSQL мы поменяли подход. Мы стали делать базы поменьше и по две реплики в каждом шарде. Это позволило нам заворачивать читающие нагрузки на реплики. То есть в Oracle всё обслуживалось с мастера, а в PostgreSQL — три машины вместо двух поменьше, и чтение заворачиваем в PostgreSQL. В случае с Oracle мы масштабировались вертикально, в случае с PostgreSQL масштабируемся горизонтально..."

То есть переехать не получилось, даже с учетом того, что стали вытягивать железом - пришлось базы резать на более мелкие. А денег на реплики Oracle изначально было жалко. Понимаю, сочувствую (с).

Знаете, что означает подчёркнутое слово "вынуждены" (если нет --- откройте словарь). А далее подчёркнутое --- это полученное от перехода преимущество.
Не смогли сделать вывод всего из двух абзацев? "Понимаю, сочувствую."

Andy_OLAP
"...В случае с PostgreSQL мы решили перейти к новой схеме, когда у нас идентификаторы уникальны в пределах одного пользователя. Если раньше уникальным был mid идентификатор письма, то теперь уникальной является пара uid mid..."

Еще и код пришлось вдумчиво менять. Не получилось логику AS IS перенести, хотя PotgreSQL Pro бьет себя пяткой в грудь, что в
рамках импортозамещения логика практически на 99% переносима. Понимаю, сочувствую (с).

Обратите внимание на подчёркнутое. Не "пришлось", а "решили". Эх, опять Вам не удалось правильно прочитать... "Понимаю, сочувствую."

Andy_OLAP
"...В PostgreSQL всё хорошо с массивами, композитами. Мы сделали денормализацию части данных..."

Жизнь заставила подумать и сделать кошерно то, что должно было быть сделано изначально правильно. Понимаю, сочувствую (с).

Да никто их не заставлял. Они этого хотели, видимо (ох уж эти мне "денормализаторы").
Можно только присоединиться к Вашему "сочувствию", но по другой причине.

Andy_OLAP
"...Поскольку нет undo, цена ошибки стала сильно выше..."

Жизнь боль, нужно 7 раз отмеривать, 1 раз отрезать, как хороший ребе при обрезании. Понимаю, сочувствую (с).

Это новая для них СУБД и временное неумение её полноценно использовать (просто опыта мало у них пока что, т.е. это в порядке вещей), например.

Andy_OLAP
"...Это список тредов в комьюнити с проблемами, которые мы самостоятельно решить не смогли.

А могли бы и не помочь. Как здорово, что у Яндекса такие друзья хорошие из комьюнити.
Но у других таких друзей меньше. И помощи иногда ждать не приходится. Понимаю, сочувствую (с).

Для того, чтобы комьюнити Вам помогло, не нужно там с кем-то "дружить".
Тоже пытаетесь незаметно протащить FUD, очень хочется?
"Поздравляю вас, гражданин, соврамши!" (C)

Andy_OLAP
"...Сюрприз. Мы столкнулись с проблемой с бэкапами. У нас recovery window 7 дней, то есть мы должны иметь возможность восстановиться на любой момент в прошлом за последние 7 дней. В Oracle размер места под все бэкапы и архивлоги был равен примерно размеру базы. База 15 терабайт — и её бэкап за 7 дней занимает 15 терабайт.

В PostgreSQL мы используем barman, и в нём под бэкапы нужно места минимум в 5 раз больше, чем размер базы. Потому что WAL сжимаются, а бэкапы нет..."

Сюрприз, что стоимость обвязки оказывается у "бесплатных" продуктов сильно больше? Ну что же, нужно было документацию читать ДО начала перехода на "бесплатное" решение, а не ПОСЛЕ. Впрочем, ничего нового (с).

Конечно, документацию читать нужно, как и правильно выбирать средства для backup.
Вывод о стоимости из этого не следует. Опять притягиваете "выводы" за уши? "Впрочем, ничего нового."

Andy_OLAP
"...Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята..."

Ай-яй-яй, как нехорошо. Жадными быть плохо. Но ведь в любой компании, не только в Яндексе, есть специалисты на C++,

Прямая ложь. Во многих компаниях ни одного специалиста по C++ нет.
Может, ещё что-нибудь попробуете "протащить"?

Andy_OLAP
который способны запатчить барман? Или не у всех такие есть? Понимаю, сочувствую (с).

Да они сделали и отослали patch!
Что же, Вы неспособны удержать в памяти только что прочитанное? :( "Понимаю, сочувствую."

Andy_OLAP
"...Ещё мы очень хотим нормальную работу с диском. В плане дискового I/O PostgreSQL сильно проигрывает Oracle..."

Какая неожиданность. Оказывается, двойное кэширование и чтение маленькими порциями не очень хорошие вещи. Понимаю, сочувствую (с).

"В плане дискового I/O PostgreSQL сильно проигрывает Oracle...", пишут нам программисты Yandex.
А они обращались к экспертам... хоть по чему-то? Или сделали этот "вывод" на основании только своих способностей?
Так же, как и Вы в "двойное кэширование и чтение маленькими порциями не очень хорошие вещи"? "Понимаю, сочувствую."

Andy_OLAP
"...Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle. Пока у нас не было крупных факапов..."

Я представил разговор - "мы готовы переехать на сервере с оракла на бесплатный postgresql, но нужно купить еще 2 таких сервера. А так все бесплатно. Только купить и все. А так - все бесплатно". Слово "пока" во фразе насчет крупных факапов тоже делает мне смешно. Впрочем, ничего нового (с).

Вы действительно ожидали переноса решения (да ещё и с изменениями "на лету"!) на другую, неизвестную им ранее архитектуру без каких-то проблем?
Вы вообще миграциями занимались, "молодой человек"? Это "делает мне смешно".
По стоимости --- тут вопрос не в "бесплатно", а в улучшении TCO. Чего они и достигли.
26 дек 18, 10:41    [21773651]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
andy st
Member

Откуда:
Сообщений: 761
softwarer
Andy_OLAP
Например, выкладка PL/SQL кода — это боль, потому что есть library cache. Если база под нагрузкой, то нельзя просто взять и обновить код функции, который сейчас используется какими-то сессиями.

Начиная с Oracle 11g2 (cентябрь 2009-го года) уже неактуально. Существует такая фича как editions, которая вот именно для подобных случаев типа яндекс.почты подходит просто идеально.

Чудная фича, гарантирующая как в процессе внедрения, так и в процессе дальнейшего использования непередаваемые ощущения и ностальгию по старой "боли от выкладки pl/sql кода".
26 дек 18, 11:20    [21773688]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58933
Блог
andy st
Чудная фича, гарантирующая как в процессе внедрения, так и в процессе дальнейшего использования непередаваемые ощущения и ностальгию по старой "боли от выкладки pl/sql кода".

Не вижу смысла обсуждать вкус устриц с теми, кто их не ел.
26 дек 18, 11:37    [21773703]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
andy st
Member

Откуда:
Сообщений: 761
softwarer
andy st
Чудная фича, гарантирующая как в процессе внедрения, так и в процессе дальнейшего использования непередаваемые ощущения и ностальгию по старой "боли от выкладки pl/sql кода".

Не вижу смысла обсуждать вкус устриц с теми, кто их не ел.

Сколько раз желудок пришлось промывать? :)
26 дек 18, 12:03    [21773717]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 2354
PgSQLanonymous3
"Ближе к делу?" К чьему это, интересно?
Явно не к моему --- сначала ответьте на заданные Вам вопросы, а потом уже я буду решать, игнорировать Ваши или нет.

Предсказуемый ответ. Не хватило сил написать, что у компании нет денег на техподдержку Postgres.

Документ "Почему Postgres - это не аналог Oracle" - это "оскорбление" и "ложь", потому что средненько характеризует уровень проектов, на которых работает Postgres и (в воображении программистов) невысоко характеризует и их - у них же может быть только хайлоад с высочайшими требованиями к производительности, надежности и качеству.
26 дек 18, 13:14    [21773775]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
"В плане дискового I/O PostgreSQL сильно проигрывает Oracle...", пишут нам программисты Yandex.
А они обращались к экспертам... хоть по чему-то? Или сделали этот "вывод" на основании только своих способностей?
Так же, как и Вы

Резюмируем - Вы лично считаете, что программисты Яндекса не эксперты и не обращались к экспертам. Понимаю, сочувствую (с)
26 дек 18, 13:23    [21773781]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Andy_OLAP
Но ведь в любой компании, не только в Яндексе, есть специалисты на C++

Прямая ложь. Во многих компаниях ни одного специалиста по C++ нет.

Это не ложь, а явный сарказм. Конечно, во многих компаниях нет ни то, что одного специалиста по C++, нет людей, который способны написать патч для бармана. Ну а раз нет - остается пользоваться бэкапами, которые внезапно для многих станут значительно больше привычных ранее объемов. Впрочем, ничего нового (с).
26 дек 18, 13:26    [21773785]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Предсказуемый ответ. Не хватило сил написать, что у компании нет денег на техподдержку Postgres.

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

Eleanor
Документ "Почему Postgres - это не аналог Oracle" - это "оскорбление" и "ложь", потому что средненько характеризует уровень проектов, на которых работает Postgres и (в воображении программистов) невысоко характеризует и их - у них же может быть только хайлоад с высочайшими требованиями к производительности, надежности и качеству.

Нет, этот документ --- это "оскорбление" и "ложь", потому что он, внезапно, состоит из лжи и оскорблений проекта PostgreSQL.
Вы так и не осилили прочитать объяснения, почему это так? "Понимаю, сочувствую." (C)

Ну как они, Ваши успехи на ниве демагогии? Ещё чем порадуете? ;)
26 дек 18, 13:26    [21773786]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Брать "на слабо" попробуйте кого-нибудь другого, Вашего уровня развития.

Я Вам очень рекомендую больше никогда не исследовать уровень развития Элеоноры в моем присутствии. Этим Вы сделаете одолжение не только мне, но и себе. Спасибо за понимание.
26 дек 18, 13:28    [21773791]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
PgSQLanonymous3
"В плане дискового I/O PostgreSQL сильно проигрывает Oracle...", пишут нам программисты Yandex.
А они обращались к экспертам... хоть по чему-то? Или сделали этот "вывод" на основании только своих способностей?
Так же, как и Вы

Резюмируем - Вы лично считаете, что программисты Яндекса не эксперты

Да, я считаю, что программисты Яндекса не эксперты по PostgreSQL, что, вообще-то, нормально (у них своя, другая работа и опыт в других областях).
Вас это удивляет?

Andy_OLAP
и не обращались к экспертам. Понимаю, сочувствую (с)

Я не увидел в их статье, чтобы они обращались к экспертам (а не просто с багами в community).
Может, пропустил? Можете процитировать?
Назвать компанию, которая предоставляла им поддержку, хотя бы?
26 дек 18, 13:34    [21773804]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 2354
PgSQLanonymous3
У меня хватает сил отвечать на вопросы людей, которые отвечают на мои, как Вы можете видеть в этой теме.
Брать "на слабо" попробуйте кого-нибудь другого, Вашего уровня развития.

А что вы тогда удивляетесь, что я вас давно стараюсь игнорировать?
С человеком с вашим слабым уровнем общаться ужасно скучно. Ответы предсказуемые, сообщить вам нечего, одни эмоции...
26 дек 18, 13:45    [21773821]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Назвать компанию, которая предоставляла им поддержку, хотя бы?

Вы не умеете работать с гуглом, раз Вам яндекс не нравится? Ну хорошо.
Ради собственной выгоды PostgresPro выпустили некачественный релиз, скомпрометировав и Постгрес, и Яндекс. - это признание Николая Самохвалова.
Николай занимается к сожалению в том числе и PostgreSQL.
Я про то, что была попытка "примазаться" к успеху Яндекса со стороны самой "продвинутой" компании среди тех, кто вообще способны хоть как-то помочь с PostgreSQL, более того, эти люди свой форк собирают. Круче их только создатели гринплама.
Понимаю, сочувствую (с).

Один из крупнейших российских вендоров PostgreSQL — компания Postgres Professional — отказался прокомментировать свое возможное участие в проекте, сославшись на «соглашение о конфиденциальности», которое «не позволяет комментировать проекты с “Яндексом”».
Впрочем, ничего нового (с).
26 дек 18, 13:49    [21773826]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3,

По Вашим утверждениям - можно было и ничего не менять при переносе из оракула в постгрес. Я правильно сформулировал?
Ведь это не разработчикам жизнь руки выкрутила, а они сами решили вдруг наконец-то чуть-чуть пооптимизировать. Но могли бы и так оставить.

Но как это коррелирует с тем, что Яндекс потратил на такой "простой" переход 10 человеко-лет, причем уровень их работников на порядок выше среднего уровня тех, кто будет сейчас в России заниматься в рамках импортозамещения переходом на "отечественные" СУБД.
26 дек 18, 13:52    [21773832]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
[quot Andy_OLAP]
PgSQLanonymous3
Брать "на слабо" попробуйте кого-нибудь другого, Вашего уровня развития.
Я Вам очень рекомендую больше никогда не исследовать уровень развития Элеоноры в моем присутствии.

У Вас что, синдром, эээ... "Элеоноры в поле From:"? ;)

Andy_OLAP
Этим Вы сделаете одолжение не только мне, но и себе. Спасибо за понимание.

Пожалуйста, не давайте мне советы такого рода.
Этим Вы сделаете одолжение не только мне, но и себе. Спасибо за понимание.
26 дек 18, 14:05    [21773843]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
У Вас что, синдром ;)

Ой-вей, Вы таки хотите поговорить о моих синдромах? Но это не та тема. Она никак не связана с "Российскими СУБД".
26 дек 18, 14:07    [21773845]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
А что вы тогда удивляетесь, что я вас давно стараюсь игнорировать?

Не удивляюсь, сказать-то Вам нечего --- одна демагогия.
Придумала чушь, поймали за руку --- в кусты. Придумала чушь, поймали за руку --- в кусты. Романтика. ;)

Eleanor
С человеком с вашим слабым уровнем общаться ужасно скучно.
Ответы предсказуемые, сообщить вам нечего, одни эмоции...

Просто замечательно! Вы не у Геббельса учились, часом? Можно, я буду Вам поклоняться? ;)
26 дек 18, 14:10    [21773849]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
PgSQLanonymous3,
По Вашим утверждениям - можно было и ничего не менять при переносе из оракула в постгрес. Я правильно сформулировал?

Где это я такое утверждал? Что-то менять приходится всегда (это как переход с ассемблера на C).

Andy_OLAP
Ведь это не разработчикам жизнь руки выкрутила, а они сами решили вдруг наконец-то чуть-чуть пооптимизировать. Но могли бы и так оставить.

Они же пишут, что решили "пооптимизировать", разве нет?

Andy_OLAP
Но как это коррелирует с тем, что Яндекс потратил на такой "простой" переход 10 человеко-лет, причем уровень их работников на порядок выше среднего уровня тех, кто будет сейчас в России заниматься в рамках импортозамещения переходом на "отечественные" СУБД.

Потому что любые подобные переходы вообще не "просты".
26 дек 18, 14:15    [21773856]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Они же пишут, что решили "пооптимизировать", разве нет?

Ну да - оптимизировать путем расширения количества серверов в 3 (!) раза. Жизнь заставила перейти с вертикального на горизонтальное масштабирование.
Но это еще не самый цимес. В комментариях под статьей на хабре, на которую я привел ссылку, есть показания работников Яндекса, которые занимались переходом. И четкое подтверждение, что на том же железе и при той же нагрузке скорость IO просела в 4(!) раза.

То есть при нагрузке на дисковую полку близко к 100% даже масштабирование серверов не спасет при переходе с нормальной коммерческой СУБД на "бесплатный" PostgreSQL. Впрочем, ничего нового (с).
26 дек 18, 14:22    [21773864]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
Вы не умеете работать с гуглом, раз Вам яндекс не нравится? Ну хорошо.

Мне просто не очень интересна именно эта cool story, если честно.
Это не более чем часть общего процесса постепенной замены Oracle на нормальные СУБД.

Andy_OLAP
Ради собственной выгоды PostgresPro выпустили некачественный релиз, скомпрометировав и Постгрес, и Яндекс. - это признание Николая Самохвалова.
Речь о пресс-релизе (для ясности).

Andy_OLAP
Я про то, что была попытка "примазаться" к успеху Яндекса со стороны самой "продвинутой" компании среди тех, кто вообще
способны хоть как-то помочь с PostgreSQL, более того, эти люди свой форк собирают. Круче их только создатели гринплама.
(Зевая) Почему Вы думаете, что это самая "продвинутая" компания среди тех, кто вообще способны хоть как-то помочь с PostgreSQL?
И почему Вы думаете, что я собираюсь защищать их практику ведения бизнеса?

Andy_OLAP
Ну да - оптимизировать путем расширения количества серверов в 3 (!) раза.

Ну да. К примеру, некоторые улучшают свою "инфраструктуру" ;) путём добавления ещё трёх (!) дисков (к имевшемуся одному) и создания из них RAID10. ;)
Т.е. это --- не улучшение, по-Вашему? А ведь работники Яндекса приводят примерно те же обоснования для своего решения...

Andy_OLAP
Жизнь заставила перейти с вертикального на горизонтальное масштабирование.
Они же пишут, что и раньше этого хотели, но не могли из-за стоимости лицензий Oracle. Читайте же Вы внимательнее. :(

Andy_OLAP
Но это еще не самый цимес. В комментариях под статьей на хабре, на которую я привел ссылку, есть показания работников Яндекса, которые занимались переходом. И четкое подтверждение, что на том же железе и при той же нагрузке скорость IO просела в 4(!) раза.
Я уже высказывал своё мнение о профессионализме работников Яндекса, и от того, что Вы ещё раз повторите цитату, компетентнее они не станут.
Если кому-то очень хочется, я могу настроить PostgreSQL и OS так, чтобы он работал на каком-то железе раз в десять (или более) хуже, чем нормально настроенный (даже и по I/O). Только что это докажет?

Andy_OLAP
То есть при нагрузке на дисковую полку близко к 100% даже масштабирование серверов не спасет при переходе с нормальной коммерческой СУБД на "бесплатный" PostgreSQL. Впрочем, ничего нового (с).

А ведь решение-то работает. Значит, спасает.
26 дек 18, 16:12    [21773979]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить