БД с лучшей производительностью вставок / сек? [закрыто]
file_put_contents создаст файл, если он не существует, и запишет в него содержимое, а не добавит, просто чтобы вы знали. Вызов его в цикле приведет к тому, что он будет постоянно перезаписывать написанную вами ссылку, пока ваш цикл не закончится, и вы получите только последнюю ссылку в вашем файле.
Следующий код записывает все ссылки в файле, по одной ссылке в каждой строке. Повторный вызов этой функции перезапишет файл со всеми ссылками, поэтому он обновится, если вы удалили страницу или создали новую.
function get_page_links()
{
$pages = get_pages( 'post_status=publish' );
// use the code below if your making a plugin
// this will be found on:
// path/to/yourplugin/links.txt
$file = plugin_dir_path(__FILE__) . 'links.txt';
// use the code below if you're making a theme
// this will be found on:
// path/to/yourtheme/links.txt
// $file = get_template_directory() . '/links.txt'
$n_handle_file = fopen($file,'w');
foreach ( $pages as $page )
{
$pagetitle = $page->post_title;
$pagelink = get_permalink( $page->ID );
echo "{$pagetitle}";
echo "\n";
echo "{$pagelink}";
fprintf($n_handle_file, "%s\n", $pagelink);
}
fclose($n_handle_file);
}
9 ответов
Если вы никогда не собираетесь запрашивать данные, то я бы вообще не хранил их в базе данных, вы никогда не превзойдете производительность простой записи данных в плоский файл.
Что вы, возможно, захотите рассмотреть, так это вопросы масштабирования, что произойдет, когда данные будут записываться в плоский файл слишком медленно, будете ли вы инвестировать в более быстрые диски или что-то еще.
Еще одна вещь, которую следует рассмотреть - как масштабировать сервис, чтобы вы могли добавить больше серверов без необходимости координировать журналы каждого сервера и консолидировать их вручную.
edit: Вы написали, что хотите хранить их в базе данных, тогда я бы также рассмотрел вопросы безопасности при хранении данных в сети, что произойдет, если ваш сервис будет взломан, хотите ли вы, чтобы злоумышленники могли изменить историю сказанного?
Возможно, разумнее хранить их временно в файле, а затем сбрасывать их в недоступное место, если ваш Интернет-фронт будет взломан.
Используйте Хранилище События ( https://eventstore.org), можно читать ( https://eventstore.org/docs/getting-started/which-api-sdk/index.html ), что при использовании клиента TCP можно достигнуть 15000-20000 записей в секунду. Если необходимо будет когда-либо делать что-нибудь с данными, можно использовать проекции или сделать преобразования на основе потоков для заполнения любого другого хранилища данных, которого Вы желаете. Можно создать даже кластер.
Если вам не нужно делать запросы, тогда база данных не то, что вам нужно. Используйте файл журнала.
Я бы использовал для этого файл журнала, но если вам необходимо использовать базу данных, я настоятельно рекомендую Firebird . Я только что проверил скорость, он вставляет около 10 тысяч записей в секунду на довольно среднем оборудовании (настольный компьютер 3-х летней давности). Таблица имеет один составной индекс, поэтому я думаю, без него она работала бы еще быстрее:
milanb@kiklop:~$ fbexport -i -d test -f test.fbx -v table1 -p **
Connecting to: 'LOCALHOST'...Connected.
Creating and starting transaction...Done.
Create statement...Done.
Doing verbatim import of table: TABLE1
Importing data...
SQL: INSERT INTO TABLE1 (AKCIJA,DATUM,KORISNIK,PK,TABELA) VALUES (?,?,?,?,?)
Prepare statement...Done.
Checkpoint at: 1000 lines.
Checkpoint at: 2000 lines.
Checkpoint at: 3000 lines.
...etc.
Checkpoint at: 20000 lines.
Checkpoint at: 21000 lines.
Checkpoint at: 22000 lines.
Start : Thu Aug 19 10:43:12 2010
End : Thu Aug 19 10:43:14 2010
Elapsed : 2 seconds.
22264 rows imported from test.fbx.
Firebird имеет открытый исходный код и полностью бесплатен даже для коммерческих проектов.
Не обращайте внимания на вышеприведенный тест, у нас внутри была ошибка.
У нас есть Insert 1M записей со следующими столбцами: id (int), status (int), message (140 char, random). Все тесты проводились с драйвером C ++ на настольном ПК i5 с диском Sata 500 ГБ.
Бенчмарк с MongoDB :
Вставка 1 млн записей без индекса
time: 23s, insert/s: 43478
Вставка 1 млн записей с индексом с идентификатором
time: 50s, insert/s: 20000
, затем мы добавляем 1 млн записей в та же таблица с индексом и 1M записями
time: 78s, insert/s: 12820
, которые все приводят к файлам размером около 4 ГБ на fs.
Бенчмарк с MySQL :
Вставка 1M записей без индекса
time: 49s, insert/s: 20408
Вставка 1M записей с индексом
time: 56s, insert/s: 17857
затем мы добавляем 1M записей в ту же таблицу с индексом и 1M записей
time: 56s, insert/s: 17857
точно такая же производительность, без потерь на mysql при росте
Мы видим, что Mongo съел около 384 МБ RAM во время этого теста и загрузил 3 ядра процессора, MySQL был доволен 14 МБ и загрузил только 1 ядро.
Эдориан был на правильном пути со своим предложением, я сделаю еще несколько тестов, и я уверен, что мы сможем достичь на 2x четырехъядерном сервере 50K вставок / сек.
Я думаю, что MySQL будет правильным выбором.
Firebird легко справляется с 5000 Insert/sec, если у таблицы нет индексов.
Если деньги не играют роли, можно использовать TimesTen. http://www.oracle.com/timesten/index.html
Полная база данных в памяти, с удивительной скоростью.
Я не знаю, почему вы исключаете MySQL. Он может обрабатывать большое количество вставок в секунду. Если вам действительно нужны большие вставки, используйте тип таблицы BLACK HOLE с репликацией. По сути, это запись в файл журнала, который в конечном итоге реплицируется в обычную таблицу базы данных. Вы даже можете делать запросы к ведомому устройству, не влияя на скорость вставки.
он хранится только по законным причинам.
А как насчет подробных требований? Вы упоминаете решения NoSQL, но они не могут обещать, что данные действительно хранятся на диске. В PostgreSQL все безопасно для транзакций, поэтому вы на 100% уверены, что данные находятся на диске и доступны. (только не включайте fsync)
Скорость во многом зависит от вашего оборудования, вашей конфигурации и вашего приложения. PostgreSQL может вставлять тысячи записей в секунду на хорошем оборудовании и при правильной конфигурации, это может быть мучительно медленным при использовании того же оборудования, но с использованием простой глупой конфигурации и / или неправильного подхода в вашем приложении. Один INSERT выполняется медленно, многие INSERT в одной транзакции намного быстрее, подготовленные операторы еще быстрее, а COPY творит чудеса, когда вам нужна скорость. Тебе решать.