longclaps, к сожалению данные на хостинге, консоли нет.
Но в phpMA значение кодировки сессии - utf8, сервер опознан как с кодировкой utf8, таблица в utf8_general_ci
А как его передать в хендлер?) собственно наибольшие вопросы вызывает именно процесс обмена данными хендлер<->main-пакет.
Параметр произвольный в хендлер, насколько я вижу, передать нельзя.
Остается вариант с "импортом" main-пакета в пакет хендлера с последующим получением "переменной" канала. НО компилятор упорно сообщает мне что main-пакет нельзя импортировать, поскольку это программа а не импортируемый пакет.
append режим тоже работает через блокировки, просто они ставятся не явно.
Очередь это интересно но это значительное усложнение которое уменьшает надежность всей конструкции. Плюс это замедление причем возможно существенное. А ответы на запись мне требуются синхронные.
Вариант с очередью хороший, да, но не под мою задачу. Еслиб работу можно было бы делать в асинхронном режиме (не ожидая ответа по результату записи) это былоб единственное верное решение.
задача там несколько другая... да и сделано не супер....
второй "поток" который захочет писать в лог получается будет ждать пока его освободит предыдущий.
А в случае если в этот момент еще и "ротация" срабатывает, то и даже не один раз..
lega: Я надеюсь завтра у меня появится все-таки время потестить незнакомые и знакомые базы под эту задачу...
Отобрал такие субд - mongo(контрольный образец), psql(json), couchdb, casandra, Hypertable... Может сразу что-то из этого стоит отмести?
lega: Да... наверное это самое близкое к желаниям...
Только нужно будет написать обертку...
1) Запись. Нужен REST сервис (чтоб дрова для использования отдельно не писать) который будет принимать текст и возвращать id после записи. Запись должна идти в несколько потоков, а значит сервис должен управлять файлами с текстами, для каждого потока свой файл, дабы не было конфликтов. Он же должен рулить чанками. Размер чанка кратен размеру сектора. При запросе на запись сервис должен проверять помещается ли текст в чанк, если нет - создаем новый. И тогда ИД будет такой: ДатаНомерпотокаНомерчанкаПозиция
Опционально можно еще gzip входящих строк прикрутить.
2) Чтение. Тот же REST по ID достает нужный кусок файла..
нет, ну если nosql вариант со хранением json ? или тоже все плохо?
Мне чертовски лень тестировать все вариацы (ES, Mongo, CouchDB, Mysql+hs(ну да этот вариант скорее всего точно можно отбросить, psql, и тд и тп)...
Потому и конвульсирвую вариантами....
Поиск 100% не понадобится, поскольку он и так есть но по обработанным данным. В качестве движка мы на sphinx остановились он экономичней по ресурсам и скорость у него суперская. Но там тоже подумаем над ES, потестим как там щас дела обстоят.
