Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, fddima, Вы писали:
f>> URL-ы с русскими символами, декорированные с помощью % — отказывался понимать, интерпретируя их как есть, — а если передавать их в 8-ми битном виде (а для этого нужно поприседать) — всё было отлично. AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding.
Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.
f>> Ещё какие-то моменты были, всех уже не помню. Дело было года 2 назад, — вот и интересуюсь — может уже исправился? AB>Он достаточно быстро развивается и обрастает функционалом. Иногда даже кажется, что слишком много на него пытаются навешать.
Просто не думаю что он хороший пример хорошего софта, хотя, конечно же если учесть его популярность — то да.
M>> Это, кстати, один самых геморройных моментов мускуля — выбор движка.
AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания")
Ничего он не почил. До сих пор движок по умолчанию
Здравствуйте, Mamut, Вы писали:
M> AB>А разве сегодня есть выбор кроме InnoDB? (MyISAM спокойно почил и используется лишь от "незнания") M> Ничего он не почил. До сих пор движок по умолчанию
Принцип наименьшего удивления, ИМХО. Я бы тоже не стал менять умолчания, которые были заложены столько лет назад. Ну а для 33 лямов записей даже сомнений быть не должно.
Здравствуйте, fddima, Вы писали:
f> AB>Эм... А можно примерчик, а то мне не совсем понятно, какие проблемы возникают в percent encoding. f> Эм. Это ж его сейчас ставить надо, пробовать. Грубо говоря — вместо того что-бы отдать файл с именем "ААА.html" — пытался искать файл "%80%80%80.html" (80 — это я к примеру). Увы, думаю концов сейчас уже не найти.
Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду
Здравствуйте, Anton Batenev, Вы писали:
AB>Сейчас проверил — нормально отдает. Возможно, бага и была, но Игорь достаточно оперативно на них реагирует. Так что можно повторить подход к снаряду
Ах тааак?!?! Тогда передавай Игорю респегд.
F>Э... а что — нельзя? Даже как crc от массива байт, полученного простой конкатенацией строк?
Нет, ну если ты точно знаешь, что одна таблица однозначно маппируется на один файл — то конечно можно взять CRC от этого файла.
А вот если это не так — а в общем случае это не так — то как тогда?
Здравствуйте, quwy, Вы писали:
Q>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс!
Пойду в сторону от основного направления партии и хаянья MySQL.
При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Здравствуйте, vladimir.vladimirovich, Вы писали:
DOO>>MySQL — хороший продукт. Просто имеет границы применимости. DOO>>Автор же почему то не стал на MS OLE DB Jet engine (aka Access) делать БД — тем не менее этот engine лежит в основе AD. VV>Автор почему-то не стал делать — это правда, может просто ему Access не попался на глаза во время придумывания архитектуры.
Автора просто супруга попросила сделать давно работающий продукт (базирующийся на open-source-скриптах, кстати) менее тормозным, с чем он справился хорошо: отклик web-приложения в удаленном браузере с 30-60 секунд сократился до 0-3.
Здравствуйте, Testator, Вы писали:
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. T>А вы каким местом думали когда выбирали СУБД и вид лицензии?
Я ничего не выбирал, меня попросили привести в чувства уже готовое, и я взялся. О своих впечатлениях отписал тут. А т.к. я уже много лет занимаюсь разработкой в области СУБД, то меня сильно обескуражило все увиденное. Вот и все.
Здравствуйте, Vamp, Вы писали:
Q>>Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. V>Я думаю, не найдется человека в здравом уме, который оспорит то, что Оракле превосходит MySql практически по всем статьям... за исключением цены.
Есть шаровой оракл, для данного проекта его, конечно, не хватило бы, но с другой стороны никто сильно и не думал что будут такие масштабы (специфический сервис, который только потом присосался к более востребованному и со временем начал тормозить).
V>Тут дело не в опенсорсе.
В нем тоже, коммерческая БД, авторы которой заявляют, что она "не хуже других", такого себе позволить просто не может. Вон, например, IB/FB вообще не позволяет переименовывать объекты БД, как бы я выкрутился, если бы она тоже индексы через одно место удаляла?
Здравствуйте, Vamp, Вы писали:
Q>>В три ночи прерываю процесс, ибо до утра должно все работать, а с учетом уже прошедших двух безрезультатных часов, времени явно недостаточно Q>>В результате пришлось создавать новую таблицу, в ней создавать нужные индексы, а потом перетягивать в нее все записи. К счастью, эта операция заняла менее четырех часов для обеих таблиц V>Я, наверное, очень тупой. Но не противоречат ли эти два предложения сами себе?
Нет, не противоречат. Потому что в первом случае кроме копирования, пересоздавались ненужные индексы (весьма тяжелые). Да и не известно еще, через какое место реализовано скрытое копирование.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, quwy, Вы писали:
Q>>Вот скажите, каким местом думал тот студент, который писал данную функциональность? Пусть его код может претендовать на звание самого красивого кода вселенной, но мне как пользователю это не важно, мне нужно чтобы оно работало быстро. Oracle удаляет индексы с больших таблиц за единицы секунд, и мне пофиг, открыт ли его код, и красив ли он. DOO>Ну видно же по описанию, что у тебя используется MyISAM
Где это видно? Используется как раз InnoDB.
DOO>P.S. На Oracle-то денег хватит? Явно тебе ведь не хватит Express Edition.
Я -- фактически приглашенный со стороны специалист, спасательный круг. А при выборе БД, руководствовались в основонм ее совместимостью с кучей опенсорсного php-кода. Так что претензии мимо кассы.
DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
Штатные управляющие программы? Дал бы в глаз тому гаду, который из написал! Хорошо, что они не обязательны в повседневной работе.
Здравствуйте, xBlackCat, Вы писали:
Q>>После модификации программного кода и запросов, возникла необходимость изменить конфигурацию индексов в таблице с примерно шестью миллионами записей, а в перспективе -- еще и в одной таблице уже с более чем 33,000,000 записей (статистика посещений большого количества сайтов). Казалось бы, что может быть проще, чем удалить ненужные индексы и создать новые на двухпроцессорной машине с RAID5 и 12GB оперативки? А вот фиг вам, это же опенсорс! BC>Пойду в сторону от основного направления партии и хаянья MySQL. BC>При некотором опыте в MySQL можно обнаружить, что создание/удаление нескольких индексов в одной таблице делается одной командой и, следовательно, за одно копирование таблиц. Надо просто все операции записать через запятую.
Может быть, в итоге я это сделал тоже за один проход, но руками. Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Sheridan, Вы писали:
S>> Я уже оччень давно говорил — не трогайте мускуль, он воняет.
AB>Да ладно — отлично работает, если его правильно работать.
Ну да, ну да. Т.е. если аккуратно обходить обильно натыканные разработчиками грабли.
Здравствуйте, DOOM, Вы писали: DOO>P.P.S. Кривых продуктов у того же Oracle хватает, но ты его почему-то не хаешь.
А его же трудно публично хаять. Пусть проблем и багов — вагон и маленькая тележка, зато багтрекер закрыт от любопытных глаз. В споре всегда можно сказать "у меня все работает" и спрятать голову в песок.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
KDK>>>Не указан тип используемых таблиц. Скорее всего данное поведение описано в доках к этому типц таблиц и на другом движке будет другое поведение.
M>>Это, кстати, один самых геморройных моментов мускуля — выбор движка.
S>Почти как в линуксе — выбор дистрибутива. Интересно, у апача есть ли аналогичная проблема или нет? Мне не попадалась вроде
мда, есть примерно тожее самое: выбор подходящего MPM (Multi-Processing Module)
Здравствуйте, frogkiller, Вы писали:
F>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
А вот интересно: перед удалением файла админ сделает копию ФС?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, frogkiller, Вы писали:
F>>Подход админа: сделать копию (потому что копию нужно делать всегда), в копии удалить индекс (потому что команду DROP придумали именно для этого), заменить исхоную базу новой.
Т>А вот интересно: перед удалением файла админ сделает копию ФС?
Смотря какой файл
Ну а снэпшот сделать рука не отсохнет — а ситуацию может спасти.
Здравствуйте, quwy, Вы писали:
Q>Проблема только в том, что для удаления индекса, копирование таблицы как бы вообще не нужно...
Не очевидно это ни разу. Я конечно многовато лет назад занимался базами данных, но помню что например в MSSQL и Oracle есть такие кластерные индексы, которые влияют на физическое расположение записей в таблице для оптимизации. И при удалении такого индекса тупое копирование таблицы тут может оказаться более дешевой операцией чем сортировка записей по-новому. Возможно для MySQL тоже есть какие-то особенности, из-за которых было сделано именно так как сделано.
И тут же вот это
