tag:blogger.com,1999:blog-1623745693417995987.post7392707800939059284..comments2022-01-18T17:40:57.028+03:00Comments on Бред программиста: Хранение данных в памятиforcehttp://www.blogger.com/profile/09205548202595699526noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-1623745693417995987.post-8115892083861791572018-03-01T19:34:39.711+03:002018-03-01T19:34:39.711+03:00Согласен, это не так все просто. И когда я говорю ...Согласен, это не так все просто. И когда я говорю про компрессию, я имею ввиду не только компрессию на базе словарей, но и column compression. <br />И все примерно так, как ты говоришь - да, в БД на диске постоянно образуются дырки. На сколько я понимаю VACUUM операция в PostgreSQL как раз с этим и борется. LSM это другая технология, которая выбирается большинством БД, которая никогда не меняет файлы, а только делать merge нескольких в один больше файл. Backend БД это очень интересная тема. Опять же, рекомендую посмотреть тот набор лекций.<br />Кстати, погуглил - SQL Server 2017 тоже поддерживает Data Compression https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/data-compression, и то же самое "In addition to saving space, data compression can help improve performance of I/O intensive workloads because the data is stored in fewer pages and queries need to read fewer pages from disk."Denis Gladkikhhttps://www.blogger.com/profile/05191772290678566369noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-11162419882044266152018-03-01T19:19:27.430+03:002018-03-01T19:19:27.430+03:00Пока только про сжатие. Тут ещё нюансы в том, что ...Пока только про сжатие. Тут ещё нюансы в том, что условный блок в 8Кб (размер страницы в MSSQL) при сжатии превратится в условные 4764 байт, соответственно, нельзя просто прочитать 100-ый блок, надо держать их адреса на диске, при этом, если мы чуть изменим данные и они станут 5000 байт, нам придётся писать в другое место, тут будет дырка. Заткнуть эти дырки в целом можно полным перестроением базы.<br />Ну и сжатие по блокам приводит к проблемам, что сжимать мелкие объёмы очень неэффективно, а большие приводят к тому, что при изменении условного бита надо перезаписать весь блок целиком. Тут весьма хорошо проседает перфоманс.<br />Если мы используем аналог Eventual Consistency, то нам чуть легче, если нет — то куча геморроя.forcehttps://www.blogger.com/profile/09205548202595699526noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-26158693762485315882018-03-01T18:51:26.759+03:002018-03-01T18:51:26.759+03:00То что ты называешь кеш стораджа это отчасти и ест...То что ты называешь кеш стораджа это отчасти и есть те самые данные. Это backend DB. И на самом деле OLTP выигрывает именно из-за другой реализации transactions (или в терминах concurrency control). Hekaton (см https://www.microsoft.com/en-us/research/blog/hekaton-breaks-through/) это был Microsoft Research проект, который и вырос в OLTP, где основная идея была реализовать Multi Version Concurrency Control. <br /><br />Говоря про скорость линейного чтения и IO. Базы данных никогда не читают только одну запись с диска, исторически потому что Spinning Disks. Все происходит на уровне блоков, и сживаются именно блоки по отдельности. Когда тебе нужна одна запись и она находится в блоке, которые не находится в кеше - в этом случае подгрузится весь блок. Поэтому сжимать его имеет большой смысл.<br /><br />Про платность понятно. Реализовать MVCC совсем не просто, поэтому есть буквально несколько нормальных реализаций, и, понятное дело, все хотят на этом заработать. <br /><br />Вообще, очень рекомендую посмотреть курсы лекций от CMU Database Group https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA - выбери любой, например, сейчас идет запись Advanced Database Systems (Spring 2018). Лектор очень классный и необычный. Вообще, я думаю, если бы кто-нибудь разобрался в этом курсе и смог бы на его основе преподавать в ЯрГУ - было бы очень круто. Denis Gladkikhhttps://www.blogger.com/profile/05191772290678566369noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-86356562047767861062018-03-01T12:35:52.002+03:002018-03-01T12:35:52.002+03:00Не, SQL именно что хранит кеш для стораджа, а не д...Не, SQL именно что хранит кеш для стораджа, а не для данных, они как раз OLTP таблицы сделали, чтобы они в памяти идеально торчали. Они даже на презентации цифры приводили по скорости и памяти (числа уже не помню, но значимые были).<br /><br />Сжатие повышает скорость линейного чтения, но начисто гробит IO, т.е. оно подходит для баз, которые в основном держат в памяти, иначе будет очень плохо (очень тяжёлые чтения и поиск по соответствующим полям). MS SQL умеет сжимать по таблицам, если явно сказать.<br />Собственно, про сжатие я долго могу говорить, у меня архиватор свой есть, я все эти грабли прошёл неоднократно :)<br /><br />Монга - отдельный разговор, с их BSON'ом и желанием всё держать в памяти — это хорошее решение было.<br /><br />По поводу In-Memory Db, думаю, но есть глобальная разница между внутренним кешем или своим правильным кешем и неким абстрактным. Банальный TCP round-trip до сервера очень долгий относительно выдёргивания из локальной памяти приложения. Но зато даёт возможность горизонтального масштабирования.<br />OLTP таблицы MS SQL не использую т.к. он платный и до недавнего времени не было под Linux, что ограничивало применение. За его стоимость проще ресурсов было подбросить :)<br /><br />Может быть в подходящем проекте попробую NoSQL, пока просто в моих и так всё быстро, особого смысла оптимизировать нет.forcehttps://www.blogger.com/profile/09205548202595699526noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-78049392160269456592018-02-28T21:45:30.070+03:002018-02-28T21:45:30.070+03:00Ну так верно, и тебе будет гораздо больше, чтобы в...Ну так верно, и тебе будет гораздо больше, чтобы в памяти было. Ты же не будешь делать table scan на каждый запрос, тебе нужны будут индексы. Это как раз следующее, что большое должно будет храниться после самих данных.<br /><br />По поводу сжатия данных, на данный момент самое медленное это как раз IO, поэтому проще прочитать меньше с диска и использовать какой-нибудь snappy, чем не сжимать. То, что некоторые базы пока не умеют сжимать - это только показатель того, что скорее всего не сделали еще, и не могут сделать в связи с историческими причинами (см https://www.citusdata.com/blog/2013/04/30/zfs-compression/ - "we demonstrated that ZFS and compression actually improves performance when queries are IO bound"). Посмотри на ту же MongoDB они перешли с MMAP на WiredTiger со сжатием и что получилось.<br /><br />И на самом деле - твоя идея это не бред, это как раз тренд, создание in-memory databases, которые держат данные на диски только для reliability. Просто выбери подходящую, см https://en.wikipedia.org/wiki/List_of_in-memory_databases и как раз Microsoft SQL Server with Hekaton (OLTP) это один из вариантов. Не очень понимаю, почему ты его откидываешь. Потому что тебе придется денормализировать данные? Ну тогда тебе точно дорога в NoSQL ;) Welcome Redis/MongoDB/etc.Denis Gladkikhhttps://www.blogger.com/profile/05191772290678566369noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-88685840902606178822018-02-28T10:50:22.505+03:002018-02-28T10:50:22.505+03:00Нет, не будет всё в памяти. Во всяком случае у MS ...Нет, не будет всё в памяти. Во всяком случае у MS SQL (ему гораздо больше нужно для того, чтобы всё в памяти было) и у Postgre (он как-то очень странно работает с кешированием)<br />С инвалидацией проблемы есть, со сжатием — SQL базы данных обычно не сжимают данные на диске, если явно не указать (проседает перфоманс сильно), и 20Gb я имел в виду именно несжатых данных.forcehttps://www.blogger.com/profile/09205548202595699526noreply@blogger.comtag:blogger.com,1999:blog-1623745693417995987.post-88089917498331370432018-02-28T01:44:39.118+03:002018-02-28T01:44:39.118+03:00Если ты даш своему DB серверу те самые 20GB - то в...Если ты даш своему DB серверу те самые 20GB - то все и так будет в памяти. Ему не нужно будет выгружать ничего и освобождать память.<br />Если ты попробуешь написать свой собственный кеш, то возникнут проблемы:<br />а) инвалидации<br />б) компрессии, 20 compressed GB on Disk is not the same as uncompressed data in memory. Либо самому нужно писать подходящии compress алгоритмы.<br /><br />В общем, ты просто напишешь свой собственный кеш и столкнешься со всеми проблемами написания этого самого кеш. Denis Gladkikhhttps://www.blogger.com/profile/05191772290678566369noreply@blogger.com