https://slinkov.ru/openforum/vsluhforumID3/89777.html Компания Tokutek открыла (http://www.tokutek.com/2013/04/open-source-tokudb-resources/) исходные тексты проекта TokuDB (http://www.tokutek.com/products/tokudb-for-mysql/) (Tokutek storage engine), в рамках которого развивается высокопроизводительный транзакционный движок хранения для MySQL и MariaDB. Вместо классических B-tree деревьев в TokuDB применяются рекурсивные индексы (Fractal Tree indexes (http://www.tokutek.com/resources/technology/)), что в сочетании с хранением данных в сжатом виде, позволяет значительно оптимизировать операции ввода/вывода. <br><br><br><br><br><br>Движок TokuDB оптимален в системах с интенсивной записью, когда требуется накапливать полученную в результате входящих запросов информацию и периодически генерировать на её основе отчёты. В качестве основных областей применения TokuDB называются конфигурации с большим числом запросов, связанных с добавлением, удалением и изменением данных, такие как социальные сети, анализ логов, рекламные сети и т.п.<br><br><br>При проведении тестов (http://www.tokutek. https://slinkov.ru/openforum/vsluhforumID3/89777.html#215 Tue, 04 Aug 2020 09:16:44 GMT 14.04.15<br>В своём блоге команда Percona заявила о приобретении компании Tokutek, разработчика движка TokuDB для СУБД MySQL/MariaDB/Percona.<br><br>Теперь даже ссылка из шапки ведёт на сайт Перконы :)<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#214 Sun, 19 Feb 2017 08:50:25 GMT а) это SQLite<br>б) это OpenLDAP<br><br>Механика запросов к БД в голове у тех, кто писал модули хранения данных к OpenLDAP (включая встроенные БД), как бы это помягче-то сказать, специфическая... Взгляните на код сами, ужаснитесь.<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#213 Sun, 19 Feb 2017 08:45:08 GMT &gt;&gt; запросы всё равно упираются в 99% случаев в разбор SQL <br>&gt; Откройте для себя prepared statement уже наконец.<br><br>Какой нафиг prepared statement в web ? На каждую страницу, на каждый коннект они убиваются.<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#212 Thu, 13 Oct 2016 13:01:39 GMT Тут на Оракле, у которого этот оптимизатор уж точно не полное г. на "больших серверах" постоянно приходится использовать хинты т.к. 1 из 100 запросов "напрямую" не отрабатывает за разумное время, и выигрыш бывает не на секунды. Ситуации когда у вас есть набор таблиц и нужна определённая выборка в течении ограниченного времени ( а не пары дней/недель что-бы как тут предлагали исходники поправить ) по нескольку раз в месяц случаются, и очень радует что в Оракле такая возможность есть, хоть по умолчанию использование её и не приветствуется ).<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#211 Wed, 15 May 2013 19:55:02 GMT Так я же не сказал "отвратительно", а всего лишь "так себе".<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#210 Wed, 15 May 2013 19:06:45 GMT &gt; Для вас новость, что дефрагментация вызывает большой I/O? :) <br><br>Да нет, неприятно, что данная СУБД не умеет повторно использовать свободное место без принудительного дефрага и просадки по I/O.<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#209 Wed, 15 May 2013 16:44:29 GMT &gt;&gt; http://www.postgresql.org/docs/9.1/static/sql-vacuum.html <br>&gt; Уже веселее. Но всё равно неприятно следующее: <br>&gt; VACUUM causes a substantial increase in I/O traffic, which might cause poor <br>&gt; performance for other active sessions.<br><br>Для вас новость, что дефрагментация вызывает большой I/O? :)<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#208 Wed, 15 May 2013 03:21:42 GMT &gt; В данном случае - как оно ведет себя под жестким write load. Ответ - так себе.<br><br>Неправильный ответ :) Ведет себя оно в разы лучше InnoDB.<br> https://slinkov.ru/openforum/vsluhforumID3/89777.html#207 Tue, 14 May 2013 19:45:25 GMT &gt; Вообще к указанному бенчу есть ряд серьезных нареканий - автор пытается по <br>&gt; сути забить гвоздь микроскопом. Под такую задачу надо in-memory database, +, <br>&gt; возможно, NoSQL, и TPS будут куда мягче и шелковистее.<br><br>Конкретный бенч раскрывает конкретную сторону конкретной медали, что от него и требуется. В данном случае - как оно ведет себя под жестким write load. Ответ - так себе.<br><br>На распространенных in-memory DB оно конечно график будет поровней и форма пилы другая (ибо иерархичность памяти никто не отменял, но ваятелям модным in-memory db про неё забыли рассказать), только вот персистенс будет уже сбоку и сколько улетит незаписанных данных при сбое -- ... А это типа бывает важно, не все же веб-апп "to-do list" на рельсах с редисом рисуют.<br><br>Что касается NoSQL - если не брать те где всё будет просто тупо медленней (Riak & Co.), то опять же, пила будет несколько иной формы ибо в том или ином виде они в большинстве своем SSTable-based - Cassandra etc. Ну а про LevelDB я выше написал.<br>