| 1.1, никто (??), 23:39, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?
| | |
| |
| 2.4, Аноним (-), 05:39, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?
We have provided a storage engine option which you can set when creating a table. For example:
create table t_zheap(c1 int, c2 varchar) with (storage_engine='zheap');
| | |
| |
| |
| 4.27, rshadow (ok), 14:50, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Дык это с незапамятных времен было. Просто всех устраивает дефолтовый. Я думаю если бы в мускуле innodb был бы изначально по умолчанию, то myisam может и не вспомнил бы никто.
| | |
| |
| 5.29, angra (ok), 16:43, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования. innodb было как минимум с четвертого мускула, но в те времена единственным его преимуществом были внешние ключи, которые большей части пыхеров были ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования в качестве дефолта.
| | |
| |
| 6.36, Аноним (-), 18:04, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования.
> innodb было как минимум с четвертого мускула, но в те времена
> единственным его преимуществом были внешние ключи, которые большей части пыхеров были
> ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования
> в качестве дефолта.
Была другая более фундаментальная причина. Пыхеры обычно обилием мозгов не отличаются, вернее -- отличаются их отсутствием. Поэтому понять недостатки myisam не могли в принципе. А чем меньше знаешь, тем лучше пища уваривается.
| | |
| |
| 7.46, angra (ok), 20:21, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Но ты то не такой, ты ведь понял недостатки MyISAM для тех задач. Так поведай о них, блесни интеллектом.
| | |
|
| 6.47, KonstantinB (ok), 20:30, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 innodb был как минимум с 3.23, и его преимуществом было всегда прежде всего то, что:
1) это честный версионник,
2) он написан не Монти сотоварищи, которые в то время слабо себе представляли, что такое ACID, а людьми, которые отлично понимают принципы разработки СУБД.
| | |
| 6.53, Аноним (-), 05:59, 08/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Регулярно вылавливаю последствия сладкой групповушки из MySQL(MyISAM)+PHP(Joomla)+ПыхПыхбибизьяна. Когда таблица логов разрастается до пары млн. строк, сайт начинает дико тупить, мыскль дико шуршит диском, запросам вечный лок. Горчишник в виде перегонки таблиц в InnoDB помогает.
| | |
| 6.71, XoRe (ok), 18:54, 13/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > но в те времена единственным его преимуществом были внешние ключи
Не единственным и не главным.
Главное преимущество innodb - поддержка транзакций (которой до сих пор нет у MyISAM).
Т.е. ничего, серьезнее личного бложика, на MyISAM лучше не делать.
А ведь много у кого на mysql завязаны деньги клиентов...
| | |
|
|
| 4.48, KonstantinB (ok), 20:37, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Начинается свистопляска аля MySQL.
В данном случае не вижу в этом ничего плохого. Проблема мыскля не в этом, а в реализации (и, до последнего времени, в дефолтном myisam).
| | |
|
|
|
| |
| 2.5, Аноним (-), 05:41, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ураааа, мы победили vacuum, vacuum больше ненужно!
> Опять...
Ну при наличии undo/rollback - действительно не нужно, нужно только purge
Vacuum/Autovacuum: We think that for delete-marked indexes we might not need vacuum, but we still need it for indexes that doesn't support delete-marking. Here, the idea is that by using undo technology we can change three-pass-vacuum to two-pass-vacuum. Currently any attempt to vacuum zheap will return error.
| | |
| |
| 3.11, Аноним (-), 08:45, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
там ключевое слово - "опять" ;-)
> Currently any attempt to vacuum zheap will return error.
я щетаю, прекрасно :-)
(то есть, по факту, сегодня эта "экономичная" разновидность стораджа растет вообще неограниченно, хотя и медленнее чем невакумленый обычный)
ну, ладно, понятно что оно еще толком не родилось, подождем еще годик, вдруг чудо все же произойдет...
| | |
| |
| 4.57, Аноним (-), 15:00, 08/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Плюсую. Однако надо помнить, что по ходу этот zheap добавляет лишние операции записи в оперативном периоде, тогда как vacuum и делается отложено и при ненадобности можно его выключить.
| | |
|
|
|
| 1.6, Это я (?), 05:49, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На тот случай, если не у всех есть fullflash схд - можно ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить вручную.
| | |
| |
| 2.40, Аноним (-), 18:14, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> На тот случай, если не у всех есть fullflash схд - можно
> ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить
> вручную.
При создании индекса можно указать целевое ТП, где данные индекса будут размещены физически.
| | |
|
| 1.10, Аноним (-), 08:38, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже нет. А обещали...
| | |
| |
| 2.35, Аноним (-), 18:00, 07/03/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
> ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже
> нет. А обещали...
Зачем вот это вот inmemory? Вы хоть немного себе представляете как типичная современная СУБД работает, а? Ну вот если честно? Во всех современных СУБД ВСЯ ОБРАБОТКА и так inmemory, и по другому не бывает. Какое ещё inmemory вам нужно? Всякие неофиты крикливые выдумают очередной деревянный велосипед и давай радоваться тому, что уже лет 30-ть как повсеместно просто используется.
| | |
|
| 1.15, лютый жабист__ (?), 10:56, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– | |
Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.
Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти 20 лет...
| | |
| |
| |
| 3.19, Аноним (-), 11:49, 07/03/2018 [^] [^^] [^^^] [ответить]
| –5 +/– |
Фактически так жестко нужно наверно лишь в 10% случаев. Упрямые бараны, делают проблему из ничего. Ну пускай дальше землю бодают, есть куча альтернатив...
| | |
| |
| 4.42, _ (??), 18:27, 07/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>есть куча альтернатив...
Это - да! Иди в садовники :)
| | |
|
| |
| 4.43, _ (??), 18:28, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Это только у жабистов или-или. У нормальных людей - и то, и другое :-р
| | |
| |
| |
| 6.60, _ (??), 17:15, 08/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
У нас частый случай, который покрывает 146% приложений, работающих с баблом.
А пиписки на заборе ... да хоть монгай рисуй :)
| | |
|
|
|
|
| 2.20, Аноним (-), 12:00, 07/03/2018 [^] [^^] [^^^] [ответить]
| +17 +/– | |
>Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.
Из серии "Самые тупые фразы в ИТ. Золотое издание" из разряда:
* 90% времени отазоустойчивость не нужна
* 90% времени бэкап не нужен
* 90% проектов хватит одной базы данных на одном сервере у одного провайдера.
Думаете, почему только 10% проектов успешны? Да потому что 90% обслуживают кретины.
| | |
| |
| 3.23, лютый жабист__ (?), 13:33, 07/03/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
>из разряда:
> * 90% времени отазоустойчивость не нужна
Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу всё умеет :) это ваше mvcc и бэкапы делать нормально не даёт, а только мееедленно и печально
| | |
| |
| 4.28, rshadow (ok), 15:02, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дык дело не в mvcc. Просто в постгре очень много чего не доделано в плане обслуживания самой БД. Даже вот миграция на новую версию без простоя можно делать только в 10-ке (логическая репликация). По факту для репликаций, бекапов пока только бубнами и сторонними проектами можно пользоваться.
Но все же караван идет...
| | |
| |
| 5.33, Аноним (-), 17:54, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
| | |
| |
| 6.41, лютый жабист__ (?), 18:26, 07/03/2018 [^] [^^] [^^^] [ответить]
| –5 +/– | |
> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
Подрастёшь, узнаешь
| | |
| |
| 7.51, Кузнец (?), 23:22, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
> Подрастёшь, узнаешь
Подрасту я уже вряд ли. Давайте лучше примеры. В Оракле переход с версии на версию редкий гемор. В Сиквеле -- не лучше. В сибасе не лучше. В ДБ2 там полная изотерика. Что ещё предложите?
| | |
| |
| |
| 9.59, Кузнец (?), 16:46, 08/03/2018 [^] [^^] [^^^] [ответить] | +1 +/– | Оракл отлично документирован Причём его освоение дёшево и доступно Слон в этом... текст свёрнут, показать | | |
| |
| |
| |
| 12.65, нах (?), 05:33, 09/03/2018 [^] [^^] [^^^] [ответить] | +/– | курсы-то полезны, просто они не для вас в основном - во всяком случае, все эти ... текст свёрнут, показать | | |
|
|
|
| 9.61, _ (??), 17:23, 08/03/2018 [^] [^^] [^^^] [ответить] | +1 +/– | Ну ужос, да Но не УЖОС-УЖОС же Ваши жабьи ЕЕ иной раз позаковыристее любо... текст свёрнут, показать | | |
|
|
|
|
| 5.34, Аноним (-), 17:57, 07/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Дык дело не в mvcc. Просто в постгре очень много чего не
> доделано в плане обслуживания самой БД. Даже вот миграция на новую
> версию без простоя можно делать только в 10-ке (логическая репликация). По
> факту для репликаций, бекапов пока только бубнами и сторонними проектами можно
> пользоваться.
> Но все же караван идет...
Но ведь это и близко не так. И репликация, и, тем более, резервное копирование в Слоне никакой проблемы не представляет. Всё, в общем-то, как и у других. Единственно, из общей массы Оракл со своим крайне удобным RMAN-ом выделяется, ну так Оракл и стоит куда дороже, чем любые коммерческие решения резервного копирования для Слона (или, скажем, для Сиквел сервака).
| | |
| |
| 6.45, Moomintroll (ok), 18:30, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Оракл со своим крайне удобным RMAN-ом
Да ладно! Вы действительно считаете RMAN удобным?
Функциональный - соглашусь.
| | |
| |
| 7.50, Кузнец (?), 23:20, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Субъективно, конечно же, но по мне это лучшее решение. Обширная функциональность, хорошая документация, отличные возможности скриптинга, понятная модель.
| | |
|
|
|
| 4.39, Аноним (-), 18:09, 07/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>из разряда:
>> * 90% времени отазоустойчивость не нужна
> Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу
> всё умеет :) это ваше mvcc и бэкапы делать нормально не
> даёт, а только мееедленно и печально
Чувак, как бэкапы связаны с реализацией mvcc в Слоне? Ты вообще хоть немного понимаешь о чём пишешь?
| | |
|
|
| 2.37, Аноним (-), 18:06, 07/03/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не
> нужно. Никуда и никак.
> Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти
> 20 лет...
Зачем тогда СУБД вообще? В файлик пишите всё подряд. К чему эта морока?
| | |
| |
| 3.56, лютый жабист__ (?), 12:47, 08/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем тогда СУБД вообще? В файлик пишите всё подряд.
Изобрёл носкль? Увы, это сделали ещё 10 лет назад. И оно уже лет 5 как вытеснило рсубд
| | |
| |
| 4.58, Кузнец (?), 16:39, 08/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Понимаете, нет никакого носкуль. Носкуль == имплицитный скуль. Т.е. вы пихаете кучу плоских данных, а затем, чаще всего крайне убогий индийский анализатор, сам за вас лепит кривую, но всю так же рэшэнал-модель. Причём делает это динамически и с непредсказуемой стабильностью результата. Сейчас нет даже на академ. уровне проработанной замены реляционной модели. А если нет модели на академ. уровне, т.е. там, где люди хоть немного отвечают за свои слова репутацией и их заявления хоть кто-то верифицирует, я таким пользоваться не стану. Поэтому пока Носкуль это секта верующих.
| | |
| 4.62, _ (??), 19:06, 08/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>Изобрёл носкль? Увы, это сделали ещё 10 лет назад.
Му-ха-ха! До чего же жабщики на всю голову волшебные! :-))))
Это 10 лет назад начали __называть__ NoSQL. Ну куда же хипсторам без хайпа :)
А так (тряся сединой на ЖЖ :) помницо в IBM/360 key-value (hashed keys) _уже_ было. И его даже COBOL-щики юзают, не то что жаберы :-)
>И оно уже лет 5 как вытеснило рсубд
В голове отдельного индивида и не такие майданы могут происходить :) На реальный мир это никак не влияет.
| | |
|
|
|
| 1.18, Аноним (-), 11:34, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выноса старых версий записей в отдельный лог отката изменений
Я не совсем понял, они этакую VCS в СУБД придумали?
| | |
| |
| 2.24, аноним 12 (?), 14:15, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё и сегмент отката.
| | |
| |
| 3.31, Аноним (-), 16:51, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
> и сегмент отката.
)))))
Исторические данные в Слоне традиционно хранились вместе в одной и той же куче отношения. Исторические данные это данные отката. Данные "наката", насколько я понимаю вы так окрестили данные повторного исполнения, хранятся в журнале транзакций. Теперь есть возможность исторические данные хранить в отдельном хипе. Сделали Слона ещё более похожим на Оракл.
| | |
| |
| 4.38, Аноним (-), 18:06, 07/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
>> и сегмент отката.
> )))))
> Исторические данные в Слоне традиционно хранились вместе
... вместе с актуальными...
| | |
|
|
|
| 1.26, Аноним (-), 14:49, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сделали таки сегменты отката. Не очень нужно, в общем-то.
Нормально настроенные autovacuum удобней, чем возьня с контролем за местом ещё и под сегменты отката.
| | |
| 1.52, Кузнец (?), 23:29, 07/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В Слоне же единственной проблемой реализации MVCC были короткие 32-битные XID-ы. Ну так эту проблему вынос исторических данных в отдельный хип не решает ни в какой мере. Да и проблемой это сложно назвать, если честно. В общем, не знаю: по-моему, Слон 9.2 был и так, в плане концепции, вполне достаточен. Дальше уже пошли куда-то... вширь.
| | |
| 1.69, DeadMustdie (??), 14:36, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > выноса старых версий записей в отдельный лог отката изменений
О да, они сделали UNDO aka ROLLBACK SEGMENT
> исключения перезаписи страниц
И похоже, добавили буферные пулы.
Интересно, почему сие произошло только сейчас? :)
| | |
| |
| 2.70, Andrey Mitrofanov (?), 16:18, 12/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Интересно, почему сие произошло только сейчас? :)
Почему сейчас? Так ентропия легла.
Манагеры ентерпрайсдебе прочитали wikipedia://MVCC и запилили в свой сейлз-буклетик к|/|ллер-фичу "как в оракле".
| | |
|
|
