Форум MySQL

1) Хм... но ведь эту операцию можно и руками сделать в том же блокноте?
2) Потянет - у нас столько за три месяца в счётчике набегает.
3) Это зависит от того, насколько часто они будут подвергаться изменениям, если их заливают и больше не притрагиваются к ним, то вообще ничего делать не нужно. Если идут постоянные изменения, то следует время от времени оптимизировать таблицы. Чинить таблицу следует только тогда, когда она поломалась, причём операция эта бесполезна, если для таблицы не поддерживается автоматическое обновление контрольной суммы строк, т.е. параметр CHECKSUM в таблице должен иметь значение 1, а не 0 (по умолчанию). Включить его можно при помощи ALTER TABLE:

ALTER TABLE tbl CHECKSUM = 1

Это значительно повысит вероятность починки слетевшей таблицы, но замедлит операции DELETE и UPDATE.

В общем базу я загрузил успешно, пришлось только засунуть в архив не целый файл размером 17мб, а разбить его на части, а потом уже заархивировать. Хостинг отказался работать с файлом такого размера (ограничение 16 мб). Кстати загрузка csv файла в базу InnoDB происходит в 10 раз быстрее. У меня возникают вот какие вопросы:

1) С помощью какой exe программы можно построчно разбить csv файл на части? Я это делал скриптом, в котором было всего 10 строк, но нужен exe. Большинство программ разбивают файл побайтно, нет ли программы, которая разбивает файл построчно. Я использовал File Shredder, а потом восстанавливал разорванные строки на сервере при помощи скрипта, но этот вариант немного неудобен.
2) Заказчик, на радостях, видя, успешную загрузку, а также нормальную работу первой таблицы, захотел создать еще одну таблицу и засунуть туда все прайсы, которые только есть в природе. В таком случае таблица будет занимать полтора миллиона строк. Как вы думаете потянет?
3) Как нужно ухаживать за такими таблицами? Через какие промежутки времени нужно выполнять оптимизацию и прочие операции? Нужно ли базу регулярно чинить?

Заранее спасибо за ответ!

Для создания дампа можно использовать запрос вида

mysql> SELECT * INTO OUTFILE 'text.sql'      -> FIELDS TERMINATED BY ',' ENCLOSED BY '"'     -> LINES STARTING BY 'INSERT INTO tbl VALUES(' TERMINATED BY ');\r\n'     -> FROM catalogs ORDER BY id_catalog;

Он создаст файл text.sql в для таблицы catalogs, результат будет выглядеть примерно следующим образом

INSERT INTO tbl VALUES("1","Процессоры"); INSERT INTO tbl VALUES("2","Материнские платы"); INSERT INTO tbl VALUES("3","Видеоадаптары"); INSERT INTO tbl VALUES("4","Жёсткие диски"); INSERT INTO tbl VALUES("5","Оперативная память");

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

Данный пост у меня еще сохранился, может кому понадобится :). Cheops, не могли бы вы еще раз привести пример запроса на поиск дампа, просто думал воспользоваться им позднее.

В общем я сделал так (пока испытываю схему на localhost):
1) Нужная база на сей раз была в формате MsAccess. Я воспользовался пунктом меню экспорт -> текстовые файлы, csv. В итоге получился csv файл размером 17,3 мегабайта. В качестве разделителей использовал точку с запятой.
2) Возникает проблема: как закачать такой большой файл на хостинг? В этой ситуации я воспользовался библиотекой PHP PCLZip (создана французами). Эта библиотека подключается через include, то есть наличия особого серверного расширения php не требует. Она позволяет создавать и работать с архивами zip.
Официальный сайт (не забудьте переключить язык):
http://www.phpconcept.net/pclzip/
Русскоязычное руководство:
http://php.russofile.ru/work_with_zip.html

Я действовал таким образом:
- запаковал csv файл в архив zip. В таком состоянии он занимает всего 1.9 мегабайт
- закачал по ftp на сервер (этот пункт условен)
- при помощи следующей конструкции считал содержимое архива в переменную:

<?   //подключаем библиотеку pclzip   require_once("../pclzip/pclzip.lib.php");   $arch = "../zip/archive.zip";   $zip = new PclZip($arch);   // Извлекаем нужным нам файл в переменную   $content = $zip->extract(PCLZIP_OPT_EXTRACT_AS_STRING);   // Получаем содержимое csv файла   $content = $content[0]['content'];   $content = explode("\r\n", $content); ?>

-массив $content состоит из 374000 строк. Что-то он слишком большой. Я разбил его на несколько массивов. В каждом было по 1000 элементов. Содержимое полученных массивов будет сохраняться в отдельном csv-файле. При обновлении базы каждый файл будет обрабатываться отдельно. Поскольку обработка csv-файла и вставка полученных данных в базу сильно нагружает сервер, размерность массивов можно увеличивать или уменьшать в зависимости от ограничений на время выполнения скрипта, установленных на хостинге.

<? $arr = array_chunk($content, 1000); ?>

-преобразуем массив в строку и сохраняем ее в отдельном файле. Имя файла определяется порядковым номером массива и состоит из трех символов (000, 001, 002 ... 374):

<? $count =  count($arr); for($i = 0; $i < $count; $i++) {   $filename = str_pad($i, 3, '0', STR_PAD_LEFT);   $fp = fopen("../csv/{$filename}", 'w');   fwrite($fp, implode("\n", $arr[$i]));   fclose($fp); } ?>

3) Пользователю предоставляется интерфейс, где он может поочередно загружать данные в базу. Что касается типа таблицы, я выбрал InnoDb как самую надежную. При загрузке происходит выборка нужных данных при помощи регулярных выражений и обновление базы (INSERT).
После загрузки пользователь получает информацию о количестве загруженных строк, также выводятся строки csv-файла, которые по каким-либо причинам не были загружены в базу. Впоследствие их можно загрузить по одной через особый интерфейс. На этой же странице можно предложить пользователю отметить обработанный файл как загруженный.

Процесс также ускорится, если удалить все ключи и восстановить их после того, как данные будут уже загружены в таблицу.

Транзакциями я не пользуюсь, но ведь известно, что если размер таблицы MyISAM превышает 10мб - начинаются проблемы, а я отдаю предпочтение надежности. Интересно, а на хостинге процесс обработки cvs пойдет быстрее? Может быть, для того, чтобы ускорить его, стоит закрыть сайт для посетителей при обновлении базы? Я думаю, это уменьшит нагрузку на сервер.
PS. Каталог будет обновляться раз в полгода.

MyISAM - это самые быстрые таблицы, практически без возможностей транзакций, так как блокировка происходит на уровне таблиц
InnoDB - это тяжеловесные таблицы, специально предназначенные для поддержки транзакций (на уровне отдельных записей)

Поэтому результат неудивителен и ожидаем, за любые дополнительные фичи и устойчивость приходится расплачиваться скоростью - тоже самое будет и при выборке (но в меньших маштабах). Если ваша база данных будет не больше 10 Гб и вам не больно-то нужны транзакции - выбирайте тип MyISAM - так именно благодаря ему MySQL носит титул одной из самых быстрых баз данных.

При использовании таблиц InnoDb у меня почему-то резко замедлилась обработка CSV файлов. Здесь речь идет об урезанных версиях csv (9000) наименований. Она происходит следующим образом:

1 csv файл:
а) выбираем при помощи регулярных выражений нужные столбцы (все кроме id, price, count)
б) после некоторой обработки стандартными функциями вставляем (INSERT) данные в базу, в столбцы price, count помещаются нулевые значения (0).

2 csv файл:
а) выбираем при помощи регулярных выражений столбцы id1 price, count.
б) ищем при помощи SELECT строку, содержащую выбранный из csv id1 (уникальный для каждой позиции). id1 - это скорее всего какой-то идентификатор таблиц MsSQL. Примерное значение - CB49C859-CE8F-11D5-975E-0050BF293E9D. В любом случае он является связующим звеном между двумя csv файлами. В приложении не используется, нужен только на этапе загрузки csv. Думаю как избавиться от него.
в) добавляем (UPDATE) price и count в запись, где находится нужный нам идентификатор MSSQL.

Я выполнил профилирование кода (здесь следовало бы замолвить доброе слово о вашей книге :). Вот результаты:

MyISAM
Обработка 1 csv файла: 6 секунд
Обработка 2 csv файла: 13 секунд

InnoDB

Обработка 1 csv файла: 193 секунд
Обработка 2 csv файла: 198 секунд

Все это тестировалось на машине Celeron 1.7Hz, 512мб оперативной памяти. Может быть у хост-провайдера конфигурация помощнее будет? :). Стоит сказать, что на стороне клиента будет использоваться только SELECT.
Что касается хостинга, то скорее всего выбор падет на Peterhost.

1) Перед транспортировкой по FTP я бы их разбил бы на несколько частей... Просто распилив по n000 строк, ведь логической единицей csv-файла, является строка.
2) Для MySQL это не размер - 30 Мб и 360000 записей она поянет без вопросов. Проблемы могут начаться при достижении 10 Гб на MyISAM таблицах, но это вполне можно обойти за счёт перехода на InnoDB, в одной корпорации (название с ходу найти не могу) на данном движке MySQL работает с 1 Тб базой!!!
3) Это в зависимости от того, что требуется - если скорость, то хорошо бы если сервер базы данных располагалася на том же сервере, что и Web-сервер, т.е. сетевой адрес базы данных был localhost, если надёжность, то следует поискать хостинг, где выделенный сервер базы данных. Учитывая размер базы, неплохо, если объём занимаемый базой данных не учитвывался бы, а оплачивалось бы только место занимаемое виртуальных хостом.

Здравствуйте. Мне нужно разместить в web каталог, насчитывающий 360000 строк. Проблема распадается на две части:
1) Обработка, 2 файлов csv, которые импортируются из базы данных MSSQL. Суммарный файлов равен 30мб. Как их лучше обработать? Продумываю такую схему: загрузить по ftp csv и обрабатывать его скриптом прямо на сервере. Здесь камнем преткновения может стать время выполнения, тогда, наверное, следует вставлять данные по частям... Какие есть идеи?
2) Сумеет ли mysql управлять таблицей размером 360000 строк? Не "треснет" ли база? В случае утвердительного ответа на предыдущий вопрос, думаю разбить каталог на несколько таблиц с разными именами, но одинаковой структурой. Таблица имеет примерно такую структуру :

CREATE TABLE catalogue (   id int(32) NOT NULL auto_increment,   id1 varchar(36),   works varchar(255),   num varchar(255),   alt_num varchar(255),   descr tinytext,   mark tinytext,   price real,   count int,   PRIMARY KEY(id_det),   index(id1) );

3) Как правильно подобрать хостинг? Какие параметры mysql важны?
Заранее благодарю за ответ.