Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
09.07.2006, 00:35
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
вопрос даже не в выборе СУБД, а скорее в возможности использования LDAP для 2-4х гигабайт текстовых данных, либо выбор наиболее шустрой СУБД для быстрой выборки информации, но при этом скорость внесения данных не имеет значения. СУБД должна работать под Linux (Debian GNU/Linux) и быть достаточно надежной, что б не возникли проблемы с восстановлением данных при малейшем сбое. Читал, что InnoDB расчитан для таких задач, но, когда пробовал его использовать - быстродействие оставляло желать лучшего (таблицу из 2000 записей читало окола минуты, а подобных записей может быть то 6*10^6) для сравнения - размер субд сравним с базами данных населения (москва/питер), только данных раз 10 больше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 01:00
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Ну, не утверждаю, что MySQL+InnoDB тут будет самым оптимальным вариантом, но надо заметить, однако же, что либо у вас сервер не был оптимально настроен для работы с InnoDB, либо запросы были неоптимально построены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 01:40
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
таблицу из 2000 записей читало окола минуты Хм. Не знаю MySQL, но имхо это совершенно фантастическая цифра. Такое впечатление, что база размещалась на дискете :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 02:25
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Всё ведь зависит от запроса,) Можно и по десяти записям такой придумать, что любой сервер помрёт считаючи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 02:27
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Отметим, что было сказано "читала таблицу", а не "считала запрос". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 05:34
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
softwarer таблицу из 2000 записей читало окола минуты Хм. Не знаю MySQL, но имхо это совершенно фантастическая цифра. Такое впечатление, что база размещалась на дискете :) Да, конечно настройка системы была не оптимальной, тем более тестировалось под Win2k, но, если сравнивать с MyISAM - разница была раз в 20, ато и 30, из-за чего тогда отказался наотрез от использования InnoDB, а если учитывать, что настроить систему можно лишь один раз, и для переноса данных надо постоянно иметь либо дампы баз, либо инструменты для работы с базами - я решил на отрез отказаться от нее, хотя в документации было написано, что InnoDB в разы быстрее работает с большими данными ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 06:27
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Какие такие инструменты? Клиент? Какие дампы, что за бред? И откуда такие безумные мифы берутся, не понимаю... Ну нету такой разницы в скорости InnoDB и MyISAM, просто нету. Да и разница в скорости проявляется не в зависимости от размера таблиц, а от соотношения количества запросов на добавление/замену/обновление/чтение записей. И тридцатикратная разница в производительности вас не заставила задуматься, может быть, тут что-то не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 15:57
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
заставило! но, желания разбираться не было.. тем более настройки были взяты из мана по MySQL (пропорции были полностью соблюдены)... так что не понятно было, из-за чего так работало все.... тем более в манах написано, что эти базы тестировались на сервере какой-то компании, где по 800 вставок / сек, и размер баз до терабайта... Действительно ли InnoDB способен работать на столько шустро? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 15:57
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
заставило! но, желания разбираться не было.. тем более настройки были взяты из мана по MySQL (пропорции были полностью соблюдены)... так что не понятно было, из-за чего так работало все.... тем более в манах написано, что эти базы тестировались на сервере какой-то компании, где по 800 вставок / сек, и размер баз до терабайта... Действительно ли InnoDB способен работать на столько шустро? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 17:11
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
DocAlДа и разница в скорости проявляется не в зависимости от размера таблиц, а от соотношения количества запросов на добавление/замену/обновление/чтение записей. Ну, имхо, не совсем верно... "Вертикальный" размер таблицы имеет большое значение, да и "горизонтальный" тож, так как зависит от кол-ва и состава полей в выборке. Это так, реплика из зала... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.07.2006, 23:52
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Я имею в виду, разница в скорости работы, в зависимости от того, используется InnoDB или MyISAM. Так-то конечно много от чего зависит, и от скорости дисковой подсистемы, и от того, фиксированной длины записи в таблицы или динамической, от... да всё не перечислишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.07.2006, 01:03
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
так все-таки, выбирать мне innoDB/MyISAM/LDAP или посоветуете что-то еще, что подойдет для моей задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.07.2006, 10:07
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
Viktor V Kudlakтак все-таки, выбирать мне innoDB/MyISAM/LDAP или посоветуете что-то еще, что подойдет для моей задачи? Из бесплатного - GT.M, коммерческого - Cache. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.07.2006, 20:32
|
|||
|---|---|---|---|
|
|||
выбор СУБД для большой БД |
|||
|
#18+
Вопрос задан неправильно. БД небольшая, и почти любая СУБД для неё подойдёт. Если поменьше и побесплатнее, то PostgreSQL или Firebird. MySQL не люблю, но и оно подойдёт. Плохой результат его (таблицу из 2000 записей читало окола минуты, вызван не плохой СУБД, а тем, что ты делаешь что-то неправильно. Вот, попытался придумать что-то максимально глупое, и получилось - если соединяться, читать одну запись и разъединяться, то будет примерно такой же эффект (соединение с базой занимает заметное время). Но число возможных глупостей бесконечно, поэтому не утверждаю, что ты делаешь именно это. Или подумай лучше, или опиши ситуацию подробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.07.2006, 18:23
|
|||
|---|---|---|---|
выбор СУБД для большой БД |
|||
|
#18+
2-4 гига любой нормальной РСУБД - семечка. Яб постгрис посоветовал из бесплатных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=35&mobile=1&tid=1553544]: |
0ms |
get settings: |
9ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 256ms |
| total: | 437ms |
| 0 / 0 |
