Исправление lesopilorama, (текущая версия) :
Эти все упорядочивания, индексы и прочие задротства нужно организовывать на языке высокого уровня по мере необходимости.
Не получается. Объясню на пальцах. Предположим, у тебя есть 10102030120301923 млрд записей в таблице. Они как-то лежат на диске. Вот то, как они лежат, очень сильно определяет скорость поиска конкретной строки по какому-то полю. Грубо говоря, если содержимое какой-либо колонки кореллирует с тем, как записи лежат относительно друг друга, то ты можешь искать в этих данных по этой колонке, если нет, то не можешь. Например есть таблица с колонками (А, B, C). Строки в этой таблице физически как лежат? Например отсортированно по (А). Тогда ты можешь каким-то (бинпоиском хотя-бы) алгоритмом искать что-то по А, потому что ткнув в серединную строку и посмотрев на её значение А можешь понять - тебе надо двигаться назад или вперёд при поиске. При сортировке строк по А, строки будут отсортированы по остальным полям ровно НИКАК от слова СОВСЕМ и найти по какому-то другому полю ты физически их сможешь только полным перебором, что полная жопа. Хочется быстрее. Хочется ткнуть в диск как можно меньшее число раз при каком-либо поиске. Даже если всё загрузить в память, то перебирать всю память - жопа отвалится. Это и есть ИНДЕКСЫ. Индекс - определённый порядок сортировки одних и тех же строк.
Дидовские программы 70хх годов ориентируют антенны по звездам и шлют массивы снимков за миллиарды километров от Земли, а этим на 20 SELECT’ов нужны 4Гб VPS.
Дидовские программы вполне себе как раз дружили со всей этой дичью - индексами, алгоритмами, структурами данных на внешней памяти: Дональд Кнут на этой теме себе имя сделал: ленты, сортировки, массивы - всё это было дико важно: объёмы данных были конские, процы были медленные, а находить отдельную запись за пикосекунду хотели уже тогда.
Исправление lesopilorama, :
Эти все упорядочивания, индексы и прочие задротства нужно организовывать на языке высокого уровня по мере необходимости.
Не получается. Объясню на пальцах. Предположим, у тебя есть 10102030120301923 млрд записей в таблице. Они как-то лежат на диске. Вот то, как они лежат, очень сильно определяет скорость поиска конкретной строки по какому-то полю. Грубо говоря, если содержимое какой-либо колонки кореллирует с тем, как записи лежат относительно друг друга, то ты можешь искать в этих данных по этой колонке, если нет, то не можешь. Например есть таблица с колонками (А, B, C). Строки в этой таблице физически как лежат? Например отсортированно по (А). Тогда ты можешь каким-то (бинпоиском хотя-бы) алгоритмом искать что-то по А, потому что ткнув в серединную строку и посмотрев на её значение А можешь понять - тебе надо двигаться назад или вперёд при поиске. При сортировке строк по А, строки будут отсортированы по остальным полям ровно НИКАК от слова СОВСЕМ и найти по какому-то другому полю ты физически их сможешь только полным перебором, что полная жопа. Хочется быстрее. Хочется ткнуть в диск как можно меньшее число раз при каком-либо поиске. Даже если всё загрузить в память, то перебирать всю память - жопа отвалится. Это и есть ИНДЕКСЫ. Индекс - определённый порядок сортировки одних и тех же строк.
Дидовские программы 70хх годов ориентируют антенны по звездам и шлют массивы снимков за миллиарды километров от Земли, а этим на 20 SELECT’ов нужны 4Гб VPS.
Дидовские программы вполне себе как раз дружили со всей этой дичью - индексами, алгоритмами, структурами данных на внешней памяти: Дональд Кнут на этой теме себе имя сделал: ленты, сортировки, массивы - всё это было дико важно: объёмы данных были конские, процы были медленные, а находить отдельную запись за пикосекунду хотели уже тогда.
Исходная версия lesopilorama, :
Эти все упорядочивания, индексы и прочие задротства нужно организовывать на языке высокого уровня по мере необходимости.
Не получается. Объясню на пальцах. Предположим, у тебя есть 10 млрд записей в таблице. Они как-то лежат на диске. Вот то, как они лежат, очень сильно определяет скорость поиска конкретной строки по какому-то полю. Грубо говоря, если содержимое какой-либо колонки кореллирует с тем, как записи лежат относительно друг друга, то ты можешь искать в этих данных по этой колонке, если нет, то не можешь. Например есть таблица с колонками (А, B, C). Строки в этой таблице физически как лежат? Например отсортированно по (А). Тогда ты можешь каким-то (бинпоиском хотя-бы) алгоритмом искать что-то по А, потому что ткнув в серединную строку и посмотрев на её значение А можешь понять - тебе надо двигаться назад или вперёд при поиске. При сортировке строк по А, строки будут отсортированы по остальным полям ровно НИКАК от слова СОВСЕМ и найти по какому-то другому полю ты физически их сможешь только полным перебором, что полная жопа. Хочется быстрее. Хочется ткнуть в диск как можно меньшее число раз при каком-либо поиске. Даже если всё загрузить в память, то перебирать всю память - жопа отвалится. Это и есть ИНДЕКСЫ. Индекс - определённый порядок сортировки одних и тех же строк.
Дидовские программы 70хх годов ориентируют антенны по звездам и шлют массивы снимков за миллиарды километров от Земли, а этим на 20 SELECT’ов нужны 4Гб VPS.
Дидовские программы вполне себе как раз дружили со всей этой дичью - индексами, алгоритмами, структурами данных на внешней памяти: Дональд Кнут на этой теме себе имя сделал: ленты, сортировки, массивы - всё это было дико важно: объёмы данных были конские, процы были медленные, а находить отдельную запись за пикосекунду хотели уже тогда.