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

Откуда:
Сообщений: 54800

PgSQLanonymous3
А вот ACID мультимастер без существенных ограничений, как уже теоретически доказано,
невозможен.

Вообще-то возможен. Синхронный мультимастер не имеет ограничений, он прост, но уныл и
способен обеспечить только fault tolerancy. Те твои теоретические "доказательства"
базируются на теоретической же модели транзакций, в которой есть только dirty read и
serializable.

Posted via ActualForum NNTP Server 1.5

24 дек 18, 15:27    [21772211]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
PgSQLanonymous3
H5N1
я могу.
postgres хранит версии измененных строк прямо в датафайлах, потому переоически разбухшим от мусора датаайлам требуется vacum, котрый зачастую ставит работу бд раком.

Нет, не "зачастую", а в исключительных случаях (когда какой-то некомпетентный DBA отключает autovacuum, например)!
Т.е. такого я не видел уже несколько лет в нормально администрируемых случаях.

ты не видел, а те кто пытались мигрировать с оракла только это и видят.

PgSQLanonymous3
А покажите ссылку на признание.


https://www.enterprisedb.com/blog/do-or-undo-there-no-vacuum

PgSQLanonymous3
Ещё раз, у каждого из обсуждаемых подходов есть плюсы и минусы.
Специально для Вас: есть ситуации, когда что PostgreSQL, что MS SQL будут "бегать вокруг ползущего Oracle" именно за счёт преимуществ в их реализациях MVCC.

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

H5N1
Ах, ну да, всё, что не как в Oracle, то "криво", как же я забыл. ;)
Технических аргументов я что-то так и не увидел, впрочем. :(

ну и дурачек. этому разделу порядка 20 лет и каждый аргумент разложен и разжеван. особливо на тему версионности.
в том числе и по readfilescattered
24 дек 18, 15:30    [21772216]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Кроме TPC-C там есть и другие, более современные тесты, которые Оракл также прошел.

Ничего себе, какая беспардонная ложь! Вы не у маркетологов Oracle учились? ;)
Ну так покажите мне хоть один результат современного OLTP теста --- TPC-E.

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

Вы приниципиально не читаете то, что Вам пишут? Или проблемы с пониманием?
Сообщество PostgreSQL делать этого не будет.
Можете перечитывать объяснения, почему это так, пока не дойдёт.

Eleanor
Его обсуждение в этой теме неоднократно происходило, например, цитирую документ "Из-за низкой производительности СУБД PostgreSQL никогда не участвует в независимых тестах производительности, таких как TPC (www.tpc.org)."

Это наглое передёргивание. См. выше.

Eleanor
И там нет никаких оскорблений в сторону Postgres, а написано как есть:
"если Вы выбираете СУБД для создания небольшой информационной системы, где простои допустимы, нет конфиденциальных данных, к скорости работы высоких требований не предъявляется, количество пользователей и объем данных невелики, то PostgreSQL вполне подходит для Вашего решения. "

Это и есть оскорбления, просто чтобы Вы знали. Т.е. PostgreSQL нагло и безосновательно смешивают с грязью.
24 дек 18, 15:56    [21772243]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Dimitry Sibiryakov
PgSQLanonymous3
А вот ACID мультимастер без существенных ограничений, как уже теоретически доказано,
невозможен.

Вообще-то возможен. Синхронный мультимастер не имеет ограничений, он прост, но уныл и
способен обеспечить только fault tolerancy. Те твои теоретические "доказательства"
базируются на теоретической же модели транзакций, в которой есть только dirty read и
serializable.

То есть ссылку Вы не читали (как обычно)?
Знаете что... когда Ваши мнения вроде "cинхронный мультимастер не имеет ограничений" начнут иметь хоть какое-то отражение в реальном мире (а не противоречить всей известной теории и практике), вот тогда они начнут меня интересовать.
24 дек 18, 16:09    [21772264]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
Dimitry Sibiryakov
Это, конечно, хорошо, но записи просто так не исчезают, их кто-то удалил

Нет, вот это неправда :) Удаление записи у меня в обязательном порядке разъезжалось по всем серверам, даже по тем, где такой записи никогда не было - как раз для предотвращения всякого рода "призраков прошлого". Вариант, когда с сервера А на сервер Б послали запись 1, а в это время на сервере Б удалили запись 2, на которую запись 1 ссылается - исчезающе редкая экзотика. Просто потому, что по бизнесу записи вообще редко удаляют, а если удаляют - то перед этим переводят в статус, когда ссылки на них исключены.

На практике вышеописанная логика перезапроса в 100% случаев срабатывала в следующей ситуации: запись 1 по правилам репликации доставили на сервера 1, 2 и 3 (и не доставили на 4, 5 и 6), на сервере 3 ей создали деталь (запись 2), и та должна быть доставлена на сервера 1, 2, 3 и 5. Вот в этом случае 5-й сервер запрашивал себе копию первой записи.

Dimitry Sibiryakov
Что делать на ноде, где к удаляемой записи есть детали и возникает ошибка нарушения внешнего ключа при попытке её удаления?

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

Dimitry Sibiryakov
А что с уникальными ключами? Что и у кого запрашивать, когда, грубо говоря, в таблицу фамилий на разных нодах добавили двух Ивановых?

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

Dimitry Sibiryakov
Самый забавный вопрос: что делать если на одной ноде поле в записи изменили с 1 на 2, а на другой - с 1 на 3?

Это не забавный вопрос, а скорее околотеоретическая ситуация. Она противоречит логике бизнеса, согласно которой у записи есть права доступа, и никакой левый перец просто так не может и не должен изменять поле. Её проще объяснить бескомпьютерной аналогией: если дело Иванова лежит в шкафу у Марь Иванны, никакой чувак из другого города не может просто так открыть его и черкнуть там пару строк. От того, что "шкаф" меняется на "сервер", логика доступа не меняется, дело Иванова по-прежнему может редактировать либо Марь Иванна, либо кто-то, кому она его отдала.

Да, в некоторых случаях предусматривали такие режимы работы. Например, это могло выглядеть так. Марь Иванна поменяла поле с 1 на 2. В это время её начальник, находясь в командировке в другом городе, взял запись себе и поменял поле с 1 на 3. В этом случае реплика Марь Иванны, добравшись до сервера начальника, отпала по причине "запись уже не Марь Иванны" и упала в ошибки репликации. Тем временем, от её начальника на сервер Марь Иванны приехали реплики сначала "беру запись себе", потом "меняю поле на 3". В результате запись стала везде "начальственной". Ну а я с утра, посмотрев на это безобразие, убедился, что всё в порядке и добавил настройку, согласно которой такая ситуация ошибкой не считается и рапортовать о ней незачем.
24 дек 18, 16:53    [21772295]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
PgSQLanonymous3
Когда речь идёт о multi-master в СУБД, чаще всего имеется в виду ACID реализация, а не наколенные не-ACID поделки, примерно так.

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

PgSQLanonymous3
как уже теоретически доказано

И это один из тех случаев, когда теоретиков можно и нужно обозвать теоретиками. Они пытаются решать задачу, которая не имеет отношения к практике - и доказывают, что её решить невозможно. Если же сосредоточиться на тех требованиях, которые идут от практики - где-то сужающих задачу, где-то дающих большую свободу и т. п. - оказывается, что они вполне выполнимы.
24 дек 18, 17:08    [21772310]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

PgSQLanonymous3
То есть ссылку Вы не читали (как обычно)?

Вообще-то читал. Но там таки нет утверждения невозможности "ACID multimaster без
существенных ограничений". Невозможность получить "всё и сразу" существенным
ограничением не является.

Posted via ActualForum NNTP Server 1.5

24 дек 18, 17:18    [21772314]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
H5N1
ну и дурачек. этому разделу порядка 20 лет и каждый аргумент разложен и разжеван. особливо на тему версионности.

Кроме личных оскорблений у тебя аргументов нет, придурок?

H5N1
ты не видел, а те кто пытались мигрировать с оракла только это и видят.

Что и неудивительно, нет?
Они же некомпетентны, и здесь их кривые подходы (как и неспособность решить хоть какую-то проблему) "не летают".

PgSQLanonymous3
https://www.enterprisedb.com/blog/do-or-undo-there-no-vacuum

Ты её хоть читал? Или знакомые слова увидел?

H5N1
в ваших кривых руках - безусловно будет. а вот в руках профи картинка ровно наоборот.

В любых руках, идиотина. Ты настолько тупой, что не понимаешь, что в "руках профи" нет никакой магии, и однозначно лучшего подхода именно к данной проблеме просто нет?
И для каждого есть ситуации, где он будет выигрывать.

H5N1
В любом банке, любая крупная oltp это исключительно оракл. почему исключительно? потому что оракл не обойти. даже на tpc-c, где у блокировочника должно быть быть по идеи громадное преимущество из-за не неужности писать в UNDO, оракл уделывает всех и вся оптом. даже на таких задачах, как tpc-c уделывает.
блокировки в блоке данных, версионность на уровне блока, настраиваемый размер блока, UNDO - у оракла слишком удачная архитектура что бы кто то там хотя бы в том же темпе бежал, потом и такая доля в серьезных организациях.

Опять понеслись пустые рекламные лозунги? ;)
24 дек 18, 18:06    [21772345]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
softwarer
Когда речь идёт о программных продуктах, чаще всего имеется в виду то, что они должны работать и решать задачи бизнеса, а не высокомерно курить в сторонке со словами "Нам это не по плечу".

А упорной реальности как-то всё равно, чего там "хочет бизнес".
Это не ситуация "не по плечу", это ситуация "нет такого плеча".
Есть более-менее общепринятое понимание того, что такое multi-master.
И подмена этого понятия на что-то совсем другое (и создание соответствующих этому программ) "решением" не является.

softwarer
Не по плечу - нахрен с пляжа, вот и весь разговор.

Ну вот и все, кто не может создать вечный двигатель --- ушли. Угадайте, кто остался? ;)

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

Да ещё как имеет! Т.е. если бы это было возможно, все существующие имитации решения бы тут же испарились. :)
Интересные, более-менее общие и практически полезные "имитации", кстати, тоже существуют (т.е. те, где, как Вы пишете далее, есть серьёзные, но приемлемые на практике ограничения).

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

Безусловно. Только не нужно при этом утверждать, что решена оригинальная задача.
Стоит называть такие решения ---"тупое шардирование", "авось-не-развалится-типа-распределённая-СУБД" или ещё как-нибудь так, чтобы соответствовало содержанию. ;)
24 дек 18, 18:43    [21772377]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
PgSQLanonymous3
А упорной реальности как-то всё равно, чего там "хочет бизнес".

Уважаемый, у Вас упоротое представление о реальности.
24 дек 18, 18:48    [21772383]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
[quot H5N1]
PgSQLanonymous3
H5N1
ну и дурачек. этому разделу порядка 20 лет и каждый аргумент разложен и разжеван. особливо на тему версионности.

Кроме личных оскорблений у тебя аргументов нет, придурок?

кроме совершенно заслуженного оскорбления тебе выдали ссылку
https://www.enterprisedb.com/blog/do-or-undo-there-no-vacuum

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


H5N1
Что и неудивительно, нет?
Они же некомпетентны, и здесь их кривые подходы (как и неспособность решить хоть какую-то проблему) "не летают".

у них в базе двойное кеширование и мусор прямо в датафайлах. да, их подходы не удачны и они это [url=https://www.enterprisedb.com/blog/do-or-undo-there-no-vacuum
]признают[/url]

H5N1
В любых руках, идиотина. Ты настолько тупой, что не понимаешь, что в "руках профи" нет никакой магии, и однозначно лучшего подхода именно к данной проблеме просто нет?
И для каждого есть ситуации, где он будет выигрывать.

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

H5N1
Опять понеслись пустые рекламные лозунги? ;)

нет, просто ты слишком туп что бы понять, что скрывается за сугубо техническими терминами, какие я перечислил. раз уж для тебя UNDO пустой рекламный лозунг, ты совершенно зря обижаешься на мои оскорбления.
24 дек 18, 18:54    [21772386]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

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

Although Oracle and IBM are TPC members and contributed to the development of TPC-E, they’ve not shown their database performance running TPC-E
Этот тест исключительно для веселых парней из Редмонда.

Причина такого подхода к тестам - Особую остроту дискуссия вокруг несовершенства TPC-D приобрела в связи с конфликтом между Microsoft и Oracle, который был вызван тем, что одна из компаний использовала предварительно подготовленные данные для выполнения нерегулярных отчетов. В связи с этим TPC решил разделить TPC-D на два теста TPC-R (business reporting) и TPC-H (adhoc querying). Точнее говоря, были переименованы версии TPC-D: модернизированная Version 2.0.1. теперь будет назваться TPC-H, а совсем новая TPC-D Version 3.0.0 получила название TPC-R.
24 дек 18, 19:01    [21772393]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

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

История конфликта. Началось с Oracle has a scalability problem with transaction
processing systems on NT. That is the reason they claim that NT does not scale. Over 90% database users use single servers, and not clusters. On NT, SQL Server 7 has the best benchmarks for SAP R/3 (2400 SD users), BaaN (3,500 BaaN ref users) and PeopleSoft (5,700
HRMS users). These benchmarks meet 95% scalability needs of SAP, BaaN and PeopleSoft users worldwide. Oracle appears to have a scalability problem on NT, not SQL Server.
, закончилось ответным ударом "As of November 1998, Oracle is the record holder of TPC-D and TPC-C benchmarks on Windows NT. In fact, Oracle’s NT TPC-C results are almost two times faster than Microsoft’s. Microsoft has never posted a TPC-D result, suggesting that despite supposed improvements in SQL Server 7, it is still not appropriate for data warehousing applications. Oracle also has record benchmarks for SAP, Baan, and Peoplesoft."

Ну а потом в Редмонде придумали TCP-E, "улучшенную" версию TCP-C.
24 дек 18, 19:13    [21772401]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

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

Да, но зато Бартунов так красиво рассказывает, что они обогнали монгу в плане использования JSONB, плюс прикрутили такие типы данных, другие типы данных, третьи типы данных. И это самая красивая и фунциональная БД во всем мире. "Да что там в мире - в России" (с)

Только со скоростью проблема, приходится вытягивать дорогим железом и дорогими dba, а так в принципе все хорошо. И будет еще лучше. Когда-нибудь. Обязательно будет. Нужно верить в лучшее. И надеяться, как это делают некоторые участники форума, которые защищают postgresql.
24 дек 18, 19:17    [21772403]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
softwarer
PgSQLanonymous3
А упорной реальности как-то всё равно, чего там "хочет бизнес".

Уважаемый, у Вас упоротое представление о реальности.

Серьёзно? Ну так предъявите вечный двигатель первого рода ("бизнес" очень хочет) или "нахрен с пляжа".
Что Вы несёте-то, вообще? ;(
24 дек 18, 19:46    [21772427]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
H5N1
кроме совершенно заслуженного оскорбления

"Заслуженные оскорбления" в технической дискуссии? Ты серьёзно, овца? ;)

H5N1
тебе выдали ссылку
https://www.enterprisedb.com/blog/do-or-undo-there-no-vacuum

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

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

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

Нет, не признают.
Они пишут, что есть ситуации (и, в основном, довольно "косые", т.е. в плохо спроектированных / реализованных решениях), где подход с undo работает лучше.
Но ты давай, цитируй, не стесняйся.

H5N1
давай, покажи ситуацию, где мог бы выиграть постгрес с его хранением мусора в датафайлах. будешь 18м, над которым я поглумлюсь на эту тему

Да просто:
BEGIN TRANSACTION;
-- <десятиминутная транзакция со многими update/insert/delete>
ROLLBACK; -- Смотри-ка, в PostgreSQL сработало мгновенно... а что же Oracle?


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

Не тебе писать о тупости. И да, UNDO --- не пустой рекламный лозунг, это просто yet another approach. Почему-то безусловно лучшим его называют особо упоротые фанаты Oracle. Интересно, почему так?
24 дек 18, 20:00    [21772439]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
<десятиминутная транзакция со многими update/insert/delete>
ROLLBACK;

Нужно найти того, кто делает десятиминутные транзакции, и "немножко расстрелять" (с)

Чтобы смягчить пафос - под спойлером анекдот на эту тему.
+

Пленум ЦК КПСС. Сталин на сцене делает доклад, все слушают в полной темноте. Вдруг в зале - "Апчхи!".

Сталин спрашивает:
- "Товарищи, кто чихнул?"
В ответ молчание.
- "Еще раз спрашиваю, товарищи, кто чихнул?"
Тишина.
- "Расстрелять первый ряд!"
Пара автоматчиков расстреливает всех зрителей первого ряда.
- "Товарищи, я еще раз спрашиваю - кто чихнул?"
Ноль эмоций.
- "Хорошо. Второй ряд расстрелять!"
Проходит казнь второго ряда.
- "Товарищи, я в последний раз спрашиваю - кто делает commit transaction и затем rollback чихнул?"
Маленький дрожащий и вспотевший от страха мужичок несмело поднимает руку и говорит "Я...".
Сталин:
- "Будьте здоровы!".
24 дек 18, 20:08    [21772443]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
PgSQLanonymous3,

давайте без обзывательств, как-то вы этим больше других увлеклись

давайте обмениваться информацией, а не обидами
вроде как не тинейджеры какие собрались
24 дек 18, 20:14    [21772447]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
Этот тест исключительно для веселых парней из Редмонда.
Вот-вот. Т.е. Oracle в нём и близко ничего достойного показать, очевидно, не может.

Andy_OLAP
Причина такого подхода к тестам - Особую остроту дискуссия вокруг несовершенства TPC-D приобрела в связи с конфликтом между Microsoft и Oracle, который был вызван тем, что одна из компаний использовала предварительно подготовленные данные для выполнения нерегулярных отчетов.
Просто для информации --- "одна из компаний" --- это Oracle.
Т.е. мошенничали в тестах, и теперь кто-то удивляется, что Microsoft (и прочим участникам TPC) это не понравилось? ;)
А когда мошенничать уже не так просто (TPC-E), "потрясающих результатов" что-то не видно...

Andy_OLAP
В связи с этим TPC решил разделить TPC-D на два теста TPC-R (business reporting) и TPC-H (adhoc querying). Точнее говоря, были переименованы версии TPC-D: модернизированная Version 2.0.1. теперь будет назваться TPC-H, а совсем новая TPC-D Version 3.0.0 получила название TPC-R.

Только вот (с сайта TPC): TPC-R is a business reporting, decision support benchmark. (Obsolete as of 1/1/2005)
24 дек 18, 20:25    [21772454]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Andy_OLAP
Этот тест исключительно для веселых парней из Редмонда.
Вот-вот. Т.е. Oracle в нём и близко ничего достойного показать, очевидно, не может.

Вы не поняли. IBM тоже не выкладывает результаты для своей DB2. Как Вы думаете, почему? Ответ - потому что Microsoft это дочерняя компания для корпорации IBM.
А почему Oracle не выкладывает? Да потому что с приходом Azure и AWS это уже не важно. Вообще не важно. От слова "совсем". А вовсе не потому, что кто-то боится проиграть.
24 дек 18, 20:31    [21772459]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Andy_OLAP
А почему Oracle не выкладывает? Да потому что с приходом Azure и AWS это уже не важно. Вообще не важно. От слова "совсем". А вовсе не потому, что кто-то боится проиграть.
а можно попросить объяснить? я вообще никакой связи не вижу

и про то что Microsoft это дочерняя компания для корпорации IBM тоже как-то удивлен, первая как минимум в 7 раз дороже
24 дек 18, 20:37    [21772465]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
PgSQLanonymous3
"Заслуженные оскорбления" в технической дискуссии? Ты серьёзно, овца? ;)

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

PgSQLanonymous3
H5N1
у них в базе двойное кеширование и мусор прямо в датафайлах. да, их подходы не удачны и они это пропущено...

Нет, не признают.
Они пишут, что есть ситуации (и, в основном, довольно "косые", т.е. в плохо спроектированных / реализованных решениях), где подход с undo работает лучше.
Но ты давай, цитируй, не стесняйся.

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

PgSQLanonymous3
Да просто:
BEGIN TRANSACTION;
-- <десятиминутная транзакция со многими update/insert/delete>
ROLLBACK; -- Смотри-ка, в PostgreSQL сработало мгновенно... а что же Oracle?


смотрю - оракл работает хоть бы хны, а постгрес встал раком, из-за vacum, который пытается вычистить гигабайты мусора.

PgSQLanonymous3
И да, UNDO --- не пустой рекламный лозунг, это просто yet another approach. Почему-то безусловно лучшим его называют особо упоротые фанаты Oracle. Интересно, почему так?

чихать на фанатов, переколбашивают все внутренности постгреса не фанаты, которые во что-то там уверовали, а серьезные спецы.
то что ты, убогий, слишком туп понять их мативы, вызывает лишь жалость.
24 дек 18, 20:57    [21772471]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
SergSuper
Andy_OLAP
А почему Oracle не выкладывает? Да потому что с приходом Azure и AWS это уже не важно. Вообще не важно. От слова "совсем". А вовсе не потому, что кто-то боится проиграть.
а можно попросить объяснить? я вообще никакой связи не вижу

Связь в том, что уже не нужно меряться, у кого больше, а нужно зарабатывать на облаках.
SergSuper
и про то что Microsoft это дочерняя компания для корпорации IBM тоже как-то удивлен, первая как минимум в 7 раз дороже

Какая разница, какие цифры и сколько нолей нарисовали как цену акций или размер капитала для одной и для другой корпорации. IBM родила Microsoft, чтобы ее не разделили как AT&T. Давно уже выкладывали на всеобщее обозрение в ЖЖ этот смешной триллер в нескольких частях, ключевое AT&T - в простонародье именовашейся грозно-ласково Ma Bell - была разбита решением суда на осколки, собирать которые продолжает AT&T по сю пору. Тогда как IBM проскочила, увернулась в тот раз.
Вы думаете, что решение о том, чем будет заниматься та или иная корпорация, принимается где-либо помимо центрального офиса в Арлингтоне? И эти решения принимает кто-то помимо "магистра Йоды", того, который учитель Рамсфелда и прочих молодых джедаев? Нужно было не выпячивать Редмонд - создали гугл, нужно было отвлечь внимание от "корпорации добра" - создали фейсбук, понадобилось - перебросили ресурсы в амазон, перевесив бостон динамикс с гугла на софтбанк. Какая разница, сколько мелочи я переложил из одного кармана своей одежды в другой, если это все вместе одно-единственное мое пальто?
24 дек 18, 21:01    [21772473]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

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

Туп и упорот тут только ты. И не привёл ни одной цитаты, что и не удивительно.
Ты думаешь, прочие участники так же не умеют читать, как и ты?

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

А по ссылке-то написано именно о некоторых ситуациях, клоун ты упоротый. ;)
Тебе показалось, что текущую реализацию заменят?
А зря. Просто добавят ещё одну настройку (storage engine, на самом деле) типа "snapshot too old", специально для пытающихся слезть с Oracle криворуких.

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

Опять врёшь, клоун? И ничего не показал, как всегда.

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

Болтай-болтай. Но лучше бы ты читать научился вместо этого. Их (декларируемые) "мативы" расписаны по ссылке. :)
24 дек 18, 21:41    [21772489]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

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

А кто говорит, что со скоростью проблема? Ну, кроме фанатов Oracle? ;)
И зачем PostgreSQL дорогие DBA? Это же не Oracle...
"Вытягивание железом", кстати, вполне имеет право на жизнь. Расчётов TCO я, кстати, что-то всё не вижу...

И, кстати, почему эти фанаты забывают о "великолепной" скорости разработки конкретных баз данных на этой их "радости" родом из 80-х?
Время разработчиков ничего не стоит, по-Вашему?

Andy_OLAP
И будет еще лучше. Когда-нибудь. Обязательно будет. Нужно верить в лучшее.

Будет. Верить ни во что не нужно, нужно просто использовать.
24 дек 18, 21:49    [21772493]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить