|
|
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
mayton Для старого магнитного диска типа HDD время поиска любого сектора занимает в среднем 6 милисекунд. а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". (и да, это я говорю про таблицу индексов щас) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:21 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". Про индексы слышали? )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:24 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза, >а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? По ключику вестимо select vasja from... where id=123 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:27 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp Алексей Роза, >Чтобы найти рандомную, незакешированную строчку среди миллиардов, уйдёт несколько секунд. По ключу? МИКРОсекунд. это когда данные уже закешированы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:27 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky Алексей Роза а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". Про индексы слышали? )) кстати, в случае мейтоновского эксперимента она будет = исходной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:28 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза PetroNotC Sharp Алексей Роза, >Чтобы найти рандомную, незакешированную строчку среди миллиардов, уйдёт несколько секунд. По ключу? МИКРОсекунд. это когда данные уже закешированы. У тебя других слов кроме "кеширование" в лексиконе нет? Кэш[1][2][3][4] или кеш[5][6][7] (англ. cache, от фр. cacher — «прятать»; произносится [kæʃ] — «кэш») — промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удалённого источника, однако её объём существенно ограничен по сравнению с хранилищем исходных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:29 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза, Сначала построй правильную реляционную модель данных. А потом задавай вопросы. В модели данные не лежат без первичного ключа PK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:32 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Вот какой подфорум, по предположительному качеству образования участников, должен был бы быть лидером по количеству и чистоте бреда? Кто бы мог подумать, что это... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:35 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp, ты зачем мне всё это пишешь, кэп? сначала научись не флудить водой, а потом приходи в мою тему. PetroNotC Sharp В модели данные не лежат без первичного ключа PK поработай с базами данных плотно, может избавишь от своих розовых бредней. bk0010 Посмотрите про In memory database (Exasol, MemSql). Может это то, что вам надо? есть сравнение с той же редиской? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:44 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
booby Вот какой подфорум, по предположительному качеству образования участников, должен был бы быть лидером по количеству и чистоте бреда? Кто бы мог подумать, что это... да не говори... в 2020 не знать, что RDBMS это мееееедленно... парадокс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:47 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза booby Вот какой подфорум, по предположительному качеству образования участников, должен был бы быть лидером по количеству и чистоте бреда? Кто бы мог подумать, что это... да не говори... в 2020 не знать, что RDBMS это мееееедленно... парадокс Вам "мееееедленно" или "в память не влазит триллион"… Поэтому топик и есть бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 22:59 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp в память не влазит триллион да научись ты уже читать! я не спрашивал такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 23:09 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза, Леша, не тешь себя. Конечно, ты в этом форуме не самый знатный бредогенератор. Волну гнать можешь, но нызенько... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2020, 23:23 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
booby Алексей Роза, Леша, не тешь себя. Конечно, ты в этом форуме не самый знатный бредогенератор. Волну гнать можешь, но нызенько... ты эту херню детсадовскую будешь писать, когда я к тебе в тему приду пофлудить. А пока волну тут гонишь ты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 00:21 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 00:56 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза PetroNotC Sharp в память не влазит триллион да научись ты уже читать! я не спрашивал такое. авторвопрос в сохранности, констистенции и скорости обработки... Как то скупо ты вещаешь мил человек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 07:07 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза mayton Для старого магнитного диска типа HDD время поиска любого сектора занимает в среднем 6 милисекунд. а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". (и да, это я говорю про таблицу индексов щас) Нет. Бд не работает так как ты рассказываешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 07:10 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". (и да, это я говорю про таблицу индексов щас) https://ru.wikipedia.org/wiki/B -дерево ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 09:25 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp Как то скупо ты вещаешь мил человек. Я вполне конкретно и чётко определил, что меня интересует Алексей Роза ни одна СУБД не умеет хорошо работать с данными, которые лежат на диске да и когда в памяти миллиард строк, тоже тупит. и нигде не говорил про то, что у меня памяти не хватает. потому что такой проблемы у меня нет. Я знаю как её обойти. Вы же начинаете сказки рассказывать про то, что в РДБМС всё чудесно и в любой момент там миллисекунды, загоняй данные туда. Я более 10 лет работаю с РДБМС, хватило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 10:12 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
mayton Нет. Бд не работает так как ты рассказываешь. да именно так и работает. Есть "горячие" данные, а есть "холодные". Когда данные загружены в память (закешированы) - это горячие. Только вот даже когда они в памяти, это всё равно абстракция и нихрена не быстро, когда подключаются джойны и сортировки. Поиск по id - самая быстрая операция, но она не самая частая. Есть и другие, гораздо более медленные. Так вот, данные в памяти лежат постоянно только у маленьких таблиц. А большие лежат на диске. И во время первого запроса они ещё "холодные". Там даже поиск по id хромает. зы: миллисекунды - это кстати много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 10:27 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Barlone, а чего только 2? Вываливай все индексы, зачем останавливаться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 10:31 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
А как реализовывается индекс по строковому полю? Что хранится в бинарном дереве? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 10:46 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
Алексей Роза есть какие-то ограничения в практическом применении векторов? если вектор вырастет до триллиона структур и будет постоянно висеть в памяти, есть ли какие-то риски? То есть памяти хватает и ты в курсе как это решать? Тогда никаких рисков. Работай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 11:06 |
|
||
|
vector на триллион объектов
|
|||
|---|---|---|---|
|
#18+
2 All Стоп гнать бочку на Алексея. Здесь мы обсуждаем вопрос а не персону. (Перчатка Таноса жжот мне руку). Алексей Роза mayton Нет. Бд не работает так как ты рассказываешь. да именно так и работает. Есть "горячие" данные, а есть "холодные". Когда данные загружены в память (закешированы) - это горячие. Только вот даже когда они в памяти, это всё равно абстракция и нихрена не быстро, когда подключаются джойны и сортировки. Поиск по id - самая быстрая операция, но она не самая частая. Есть и другие, гораздо более медленные. Так вот, данные в памяти лежат постоянно только у маленьких таблиц. А большие лежат на диске. И во время первого запроса они ещё "холодные". Там даже поиск по id хромает. зы: миллисекунды - это кстати много. Ты затронул интересный и сложный вопрос. Я по нему могу говорить часами. Но для начала. Давай просто сделаем такой confirm, что алгоритмы поиска на диске в принципе ничем особо не отличаются по complexity от алгоритмов по оперативке. Формула - таже самая. С логарифмом в основе. Тоже самое B+Tree дерево - это сжатое в блоки бинарное дерево поиска. Только надо сделать скидку на физическую организацию данных. И на то что seek time это бич всех механических дисковых систем. а причём тут сектор? откуда БД знает, в каком секторе лежит нужная строка?? она сначала будет ВСЕ строки с диска в память тащить, а потом в них будет искать нужную. это и называется "кеширование". Современные диски оперируют блоками (LBA), поэтому разумно действительно перейти на блоки. Для большинства жестких дисков блок == 4 килобайта или 8 секторов по 512 байт. Каким образом приложение может работать с блоками. Есть такой договорняк что все файловые системы (NTFS/ext4/...etc) начинают свой файл на границе блока. Тоесть если ты открыл файл в режиме RandomAccess и будешь делать seek по смещению кратному 4к то диск при этом будет делать минимальное число операций (access path) для того чтобы тебе предоставить данные. Разумеется режим открытия файла должен быть соотвествующий (без буферизации). Здесь уже надо читать доки на API который ты используешь. Далее - простая арифметика. Если твой индекс состоит из страниц равных 4к или 8к (Oracle by default) тогда будет работать та формула которую я предложил выше. Да милисекунды это долго. Дольше чем просто память. Но обычно все DBMS прогревают в кешах корневые вершины индексов и если с индексом долго работать то в учет времени можно брать уже листовые узлы. Кстати ты до сих пор не рассказал свою задачу. Если мы ее будем знать то сумеем придумать access path такой короткой длины чтобы оперативная память и диск работали в тандеме и находили данные так быстро как только возможно. Есть также альтернативные разработки (dbms Tarantool) которые улучшают даже B+Tree индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2020, 11:17 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=39972571&tid=2017354]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 277ms |
| 0 / 0 |
