Sergei Obrastsov c127
А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

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

вот ведь забавно. сколько раз уже объясняли, что при необходимости ввести
новый индекс он просто создается и все. и в SQL его надо создавать, и в M
его надо создавать. в SQL это менее затратно? согласен. за удобство
работы с данными нужно платить.
В который раз спрашиваю: в чем именно состоит удобство работы с данными? В том что программы в 3 раза длиннее? Так это скорее неудобство.

Потом индексы в КЕШ-е создаются медленнее, получается если создать-посмотреть аналитику-убить, то может получиться что займет больше времени. Правда и места больше.

Насколько быстрее МуСКЛ создает индекс? Не могли бы Вы привести цифры, у Вас же они оба на одной машине. А то по размерам файлов, где КЕШ выигрывает приводятся конкретные цифры, а по созданию индекса, где КЕШ проигрывает - только признание, что таки медленнее. Двойные стандарты получаются.


Sergei Obrastsov
c127
Sergei Obrastsov
а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)
Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

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

Не нужно выжимать из меня слезу, мы не в церкви. Вы систему на 10 млн пользователей на этих дисках сертифицировали, или может предлагаете своим клиентам хранить работать с промышленными базами на 80Гб ИДЕ дисках с фат32? Так к чему эти разговоры о бедных? Экономить нужно там где это действительно дает экономию, а не покупать сервер БД за сотню тысяч, а потом экономить по 20 долларов на дисках. В любом случае 10Гб было бы дешевле, почему же Вы остановились на 80Гб, раз зарплата маленькая, экономили бы уже по полной.

Sergei Obrastsov
c127
Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией.

кол-во зарегистрированных сотовых телефонов в городе по годам:
как там будет выглядеть рост кол-ва звонков по ним?

Как арфиметическая прогрессия разумеется. Пусть каждый пользователь делает J звонков за интересующий нас период, тогда у одного пользователя будет
1*J звонков,
два пользователя - J+J звонков,
....
N пользователей - N*J звонков
N+1 пользователь - N*J+J звонков
....
То есть каждый следующий "на" J звонков больше предыдущего, а не "в" J раз, как это должно было бы быть в случае геометрической прогрессии. Еще раз повторяю, не растет база в геометрической прогрессии, неоткуда ей там взяться.

Sergei Obrastsov
я понимаю, что хочется "погнуть пальцы и постучать копытами". но может
лучше это делать не здесь?
Лучше выучить что такое арифметическая прогрессия, или же не использовать непонимаемые слова.

Sergei Obrastsov
c127
Sergei Obrastsov
эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,
СКЛ числа не пакует.

пакует. в 2 байта, в 4 байта... для меня это упаковка.

Числа СКЛ сервером не пакуются, тут нечего обсуждать, а то получится как с геометрической прогрессией. Они хранятся в двух байтах, четырех, восьми и т.д. И что очень важно - как хранятся, так и обрабатываются, в этом же формате. Не тратит сервер времени на упаковку-распаковку, это родной формат современных процессоров. То что КЕШ поступает по-другому и хранит все в строках это его проблема и не повод чтобы весь мир под него подстраивался и менял систему понятий.




Sergei Obrastsov
v13 - заданный список
v14 - заданный список

Что такое заданный список?

Sergei Obrastsov
размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно.
В таком случае говорить не о чем, нужны все индексы. Но ведь такого не бывает, обычно используется несколько процентов возможностей системы. У Вас ведь тоже нет всех индексов. Из всех Ваших запросов, которых по самым скромным оценкам не менее 2^13=8192, будут использоваться штук 10. Их нужно оптимизировать, остальные - пусть ждут, но скорее всего они никогда не встретятся.

Sergei Obrastsov
50% на 100Gb - существенная разница.

50% это и в африке 50%. Разница в цене диска долларов 10, если это сущестенно, то да, разница существенная. Но тогда нужно переходить на файерберд, он бесплатный, экономия на сервере БД.

Sergei Obrastsov pgresзаинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

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

а вот "размер данного" - это да, система дольше читает.

Согласен, вывод противоречит законам физики. Поиск происходит даже если используется индекс. Если КЕШ использует древовидные индексы, то у них рост примерно O(log2(N)). Это немного, но заявлять что от количества даннных не зависит неверно.

А вот зависимость от размера данных очень подозрительна. Не строки ли, в которых хранит данные КЕШ в этом виноваты? Не должно заметно зависеть, если система не качает эти данные на клиент, а при выполнении запроса она их туда качать не должна, только результат.