Bigdata - на чем делать большую базу

Статус
В этой теме нельзя размещать новые ответы.
noggano - Моя игра
noggano - Мама
noggano - урбан
Eminem - Not Afraid
так как индексы будут вешаться на такие строковые данные, эти индексы будут очень большими, а большие индексы могут не вмещаться в память => тормоза
если будет выборка без LIKE, а например,
Код:
WHERE `name` = 'noggano'
то для таких запросов можно сделать вот что:
Код:
WHERE `name` = 'noggano' AND `name_crc` = CRC32('noggano')
В `name_crc` - будет храниться CRC32 для строки, и по этой колонке необходимо построить индекс.
Таким образом, будет выбран "компактый" индекс по CRC32, а чтобы не попасть на коллизии - вторая проверка `name` = 'noggano'.
Код:
`name_crc` int(11) unsigned NOT NULL

Заполнени name_crc - повесить на триггер:
Код:
DELIMITER $$
CREATE TRIGGER `name_crc_fill` BEFORE INSERT ON `my_table`
  FOR EACH ROW BEGIN
    SET NEW.name_crc = CRC32(NEW.name);
  END $$
DELIMITER ;
 
mysql базы тянут вес в 60-100 гигабайт и не важно сколько записей , главное хороший грамотный код и структура базы данных, если совсем все туго и не тянет тогда
PostgreSQL если интересно повыделываться можно заморочится и mongo db , но я бы советовал на mysql ориентироваться по простоте
 
Делали сравнение баз реляционных - на большом количестве данных все работают одинаково (что платные, что бесплатне)

а где посмотреть результаты и выкладки этого сравнения?
К сожалению, внутреннее и непубликуемое. Но при больших данных все себя показали одинаково практически. На мелких да, разница есть.
 
Последнее редактирование модератором:
Делали сравнение баз реляционных - на большом количестве данных все работают одинаково (что платные, что бесплатне)
а где посмотреть результаты и выкладки этого сравнения?

К сожалению, внутреннее и непубликуемое. Но при больших данных все себя показали одинаково практически. На мелких да, разница есть.
можно просто перечень решений и объем тестовой базы
 
Последнее редактирование модератором:
Сравнивались MySql, MSSQL, Oracle, Postgresql. Объём - 40 гигов записей по разным таблицам.

На маленьких объёмах хорошо работал MySQL, далее все сравнялись.
 
Оу, у нас не совпали понятие о больших и маленьких базах )))
Один из клиентов моей компании имеет базу общим объемом более 10 ТБ на Оркале и все попытки наших инженеров перейти на что-то более гуманное для кошелька и не потерять в производительности пока не принесли успехов (конечно многое упирается в список поддерживаемых, но все же).
А маленькие базы до 200Гб не доставляют неудобств даже на mysql, т.к. при большой нагрузке их можно загонять в рамдиск
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху