|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 08 Feb 2004 21:35:24
To : Edward Muhutdinov
Subject : Re: вопрос по mysql
--------------------------------------------------------------------------------
Edward Muhutdinov -> All @ Tue, 03 Feb 2004 23:48:00 +0300:
EM> По причине забоданности из-за падений баз под DB_File решил
EM> переработать скрипт на использование в качестве базы mysql. Фокус в
EM> том, что к базе DB_File делается масса (порой до нескольких тысяч)
EM> запросов со случайной выборкой (не листинг), и от этого избавиться
EM> никак не получится, скрипт такой. Hо при подобной же выборке при
EM> использовании mysql выявились невероятные тормоза. То, что на
EM> db_file проходит менее чем за полсекунды (порядка полтысячи
EM> запросов на чтение и сохранение), на mysql занимает минуты три. Для
EM> получения значения используется примерно такая процедура:
EM> $val=$dbh->selectrow_array("select value from TABLE where
EM> name=(?)",{},$key)}
EM> (на db_file, соответственно, $base->get($key,$val))
EM>
EM> Я в mysql раньше не работал, может, чего-то важного не понимаю?
А вообще с реляционными базами работал? unique index по name есть?
EM> Подскажите, пожалуйста. И если mysql для этого малоподходящ, то что лучше
EM> использовать? Важно, чтобы обеспечивалось бинарное дерево и
EM> сохранение/получение пары key:value.
Вообще, конечно, обычно dbm'ки лучше подходят для хэшей, чем нормальные
реляционные базы данных и даже чем мыскль. Hамного лучше. Так что я бы
чинил DB_File. С деревьями вопрос более сложный - это зависит от того,
для чего они, собственно, нужны, и как строить работу с ними. Потом,
реляционка лучше отдает большие объемы за один запрос, чем за
несколько. Если ты заранее знаешь, что тебе нужно много данных -
старайся запрашивать все одним куском. Иногда имеет смысл поднапрячься,
получить хорошее понимание реляционных баз и сделать в базе структуру,
позволяющую запрашивать данные одним куском. Часто бывает, что хэши
использовались не по делу, а просто потому, что ничего другого dbm не
умеет, а на самом деле имелась в виду структура, которая на реляционку
ложится хорошо, но иначе.
--
Artem Chuprina
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
