Чем заменить MySQL или что лучше, чем MySQL?

Нужно увеличить скорость работы скрипта и уменьшить нагрузку на сервер. В связи с этим ищу альтернативные способы хранения информации, которые менее требовательны к ресурсам и в связи с этим могут обеспечивать большее быстродействие.

 

для простых запросов, и простых задач можно использовать SQLite, нагрузки будет несколько раз меньше

 

nick777 ресурсы и быстродействие - обычно связаны обратно пропорционально. Рекомендую прежде чем искать счастья в других СУБД рассмотреть как вы работаете с текущей. Проанализируйте все запросы, их количество и попытайтесь оптимизировать

 

Gifts, тогда посоветуйте более быстрый способ хранения данных.

 

Обязательно посмотрим в сторону noSQL например mongodb, если нужна 100% совместимость с MySQL тогда MariaDB или Percona, это форки от мускуля. Сам всё пересадил на перкону.
Удачи

 

nick777

Чтобы упереться в производительность мускуля - надо достаточно хорошо постараться, даже если очень экономить на хостинге. Вся проблема обычно в неумении пользоваться им

 

Если нужна оптимизация, то стоит писать свою БД под свои нужды. Посмотри в сторону NoSQL баз данных — MongoDB, Cassandra, etc

 

можно заменить MYSQL - файловой системой, впринципе хороший вариант.. если на сервере очень много места

 

MongoDB или CouchDB,а сервер советую переписать на node.js

 

Возможно эта статья сможет помочь тебе в выборе

http://www.xakep.ru/post/55801/

Название статьи "Жизнь после MySQL: выбираем замену для популярной СУБД"

 

ИМХО, тебе нужно переходить на SQLite

Вот тесты проведеные на машине:AMD 1.6ГГц Athlon, 1Гб ОЗУ, хард EIDE,OS Red Hat Linux 7.2.В тестирование "участвовали" MySQL,SQLite,PostgreSQL.
1)Вставка 1000 записей:
CREATE TABLE t1(a INTEGER,b INTEGER,c VARCHAR(100));
INSERT INTO t1 VALUES(1,13153,'one');
INSERT INTO t1 VALUES(99,45,'two');
INSERT INTO t1 VALUES(99,45,'three');
...995 строк пропущено
INSERT INTO t1(737,747,'nine hundred ninety-nine');
INSERT INTO t1(737,747,'thousand');
Результаты первого теста в секундах:





2)Выборка без индексов
BEGIN;
SELCT cout(*), avg(b) FROM t2 WHERE b>=0 AND b
SELCT cout(*), avg(b) FROM t2 WHERE b>=100 AND b
...96 строк пропущено
SELCT cout(*), avg(b) FROM t2 WHERE b>=9800 AND b
SELCT cout(*), avg(b) FROM t2 WHERE b>=9900 AND b
COMMIT;

Результаты 2 теста:



3)Выборка со сравнением строки:

BEGIN;
SELECT cout(*),avg(b) FROM t2 WHERE c LIKE '%one%';
SELECT cout(*),avg(b) FROM t2 WHERE c LIKE '%two%';
...96 строк пропущено
SELECT cout(*),avg(b) FROM t2 WHERE c LIKE '%ninety nine%';
SELECT cout(*),avg(b) FROM t2 WHERE c LIKE '%one hundred%';
COMMIT;
Результаты 3 теста:



4)В качестве сложного запроса будем использовать запрос,состоящий из 25000 операторов:
BEGIN ;
UPDATE t2 SET c='one' WHERE a=1;
UPDATE t2 SET c='two' WHERE a=2;
...24996 строк пропущено
UPDATE t2 SET c='two hundred eighty three thousand ninety nine' WHERE a=24999;
UPDATE t2 SET c='finish' WHERE a=25000;
COMMIT:

Результаты 4 теста:

 

Dreik лолшто это, ксерокопия книжки 90х годов от какого-то 'гуру'?

 

Да ты прав скрины из книжки, но 2007 года, а эти тесты(и не только) были опубликованы на sqlite.com.

P.S Если ты не вкурсе то SQLite выпустили в 29 мая 2000 года,о каких 90 ты имел ввиду?

 

Dreik манера изложения некоторых авторов не изменилась, а люди продолжают им верить. Внимательный читатель бы прочел баннер на http://www.sqlite.org/speed.html

А также посмотрел бы на версии остальных СУБД. Не стоит безоговорочно верить авторитетам.

 

Да не спорю данные устарели, но SQLite не переставал развиваться как и MySQL. А, автору темы я бы посоветовал использовать SQLIte либо Oracle