172 похожих чатов

>Т.Е. где-то 8 терабайт? Вы встречали такие реальные таблицы?


Ну Вы же где-то нашли таблицы рамером 32 Tб ? :)

>Индексы как раз и предназначены для того, чтобы "не влезать в память с запасом", нет? ;)
Сейчас память дешёвая и её много. Большинство баз просто целиком влезает в память и тогда никакие трюки не нужны. Разве что для прогрева кэша при старте.
Но когда всё-таки не влезает, то партишининг помогает хотя бы индексы запихнуть в память.

>индексированной по "(date, something)", и при одинаковых запросах мы работаем с какой-то частью её индекса
Если мы добавляем дату в качестве первого ключа всех индексов, то да - мы работает примерно с той же частью индекса как и обычный индекс по сегментированной таблице. С одним маленьким добавлением, что добавление даты увеличивает размер индекса примерно вдвое.
Если же мы это не делаем, то случайный досуп по вторичному инлдексу будем прыгать повсему большому дереву.

>"распределить" = "забудьте об ACID"
Не совсем так. У нас есть pg_shardman, которое наше начальство никак не решитсчя выложить воткрытый доступ. Там есть эти буковки.
Кроме 'С' это вообще делается штатными средствами посгреса: postgres_fdw + 2PC.

1 ответов

8 просмотров

> Ну Вы же где-то нашли таблицы рамером 32 Tб ? :) Ну, я нашёл то, что было бы таблицами размером в 32 Тб (на самом деле, меньше), если их не партиционировать. :) > Большинство баз просто целиком влезает в память и тогда никакие трюки не нужны. Отчасти, это так. Тем не менее, индексация (да и правильно применённое партиционирование) необходимы для типичных случаев OLTP. > С одним маленьким добавлением, что добавление даты увеличивает размер индекса примерно вдвое. Т.е. почему-то "date" во всех индексах Вы "теряете". А это значит, что все запросы по "узким" диапазонам date (не отбрасывающие много rows по другим условиям) проиграют. > Если же мы это не делаем, то случайный досуп по вторичному инлдексу будем прыгать повсему большому дереву. Конечно будет, но когда партиционирование сравнивают с индексацией, подразумевается, что мы это делаем (создаём аналогичные индексы). Т.е. если "там" было (date, something), то и тут будет (date, something), и т.д. И не забывайте, что мы можем сделать и CREATE INDEX ON t(something) WHERE date_field >= '2019-01-01' AND date_field < '2019-02-01', и проблемы с двойным размером тогда тоже нет. ;) > Не совсем так. У нас есть pg_shardman, которое наше начальство никак не решитсчя выложить воткрытый доступ. Там есть эти буковки. С примечаниями "мелким шрифтом"? ;) Я к тому, что "прозрачный" распределённый ACID без существенных ограничений (которые, зачастую, запросто сводят на нет все преимущества distributed database) теоретически невозможен. Т.е. если это решение "подходит" для данной базы (её легко шардировать) — замечательно, нет — это вообще не решение. :( > Кроме 'С' это вообще делается штатными средствами посгреса: postgres_fdw + 2PC. Ну, на основании этих средств, и это очень непросто.

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта