Встала задача создать базу данных на файлах, так как по определённым причинам использовать СУБД нет возможности.
Необходимые возможности:
- Хранение огромного количества информации
- Читабельный и понятный простому юзеру внешний вид базы данных (без сериализирования, и т.д.)
- Отсутствие большого количества файлов, возможность легко перенести на другой сервер
- Низкая нагрузка на сервер
- Скорость чтения произвольной записи из базы не более 5 секунд
- Автоматическая запись в базу не обязательна, конечный размер базы данных не важен. (доступно несколько сотен гигабайт)
Доступные средства:
- Абсолютный доступ к серверу (исключение - не разрешается ставить SQL СУБД)
- Возможность использовать любую операционную систему семейства Windows
- Веб-сервер Apache, PHP 5 + Perl, полный доступ ко всем конфигам.
Можете подсказать какую-то идею, по решению поставленной задачи?
Если бесплатных идей ни у кого нету, огласите пожалуйста цену вопроса
Заранее огромное спасибо.
Спустя 3 минуты, 27 секунд (5.06.2011 - 22:07) waldicom написал(а):
SQLite ?
Хотя она не полностью подхожит под "Необходимые возможности:". Да и вообще эти самые "Необходимые возможности:" улыбают. Это кто такие требования ставит?
Хотя она не полностью подхожит под "Необходимые возможности:". Да и вообще эти самые "Необходимые возможности:" улыбают. Это кто такие требования ставит?
Спустя 13 минут, 4 секунды (5.06.2011 - 22:20) Faantoom написал(а):
waldicom, к этим "необходимым возможностям" в комплекте идёт такой бюджет, что только изза него стоит поискать решения =)
SQLite насколько я понял, тоже СУБД... а нужно именно хранение в файлах.
SQLite насколько я понял, тоже СУБД... а нужно именно хранение в файлах.
Спустя 56 минут, 16 секунд (5.06.2011 - 23:16) fallow написал(а):
А написать?
В чём проблема?
Вообще не вижу проблемы, пока. Пишешь механизм и выводишь всё в красивый итерфейс управления, ну а что ещё?)
В чём проблема?
Вообще не вижу проблемы, пока. Пишешь механизм и выводишь всё в красивый итерфейс управления, ну а что ещё?)
Спустя 3 минуты, 35 секунд (5.06.2011 - 23:20) Игорь_Vasinsky написал(а):
полностью согласен.
Спустя 7 минут, 5 секунд (5.06.2011 - 23:27) Basili4 написал(а):
Faantoom
все субд хранят данные в файлах SQLite эта та самая субд которая работает с файлами а Вам предоставляет интерфейс в виде SQL.
Если у вас большой проект то вам в любом случае приведется писать класс или набор функций для работы с файлами т.е. реализовывать некую свою СУБД. В случае с SQLite это уже готово. И какой бы заказчик не был упертым, тот факт что SQLite всего лишь прослойка между файлами и вами как программистом не оспоришь. Можно не говорить он не как о субд а об одном из расширений php как например cUrl или iconv. Короче ссыте в уши заказуну. Иначе ваш заказ можно сравнить с заказом дышать под водой без соответствующих приспособлений за любые деньги не сможете.
все субд хранят данные в файлах SQLite эта та самая субд которая работает с файлами а Вам предоставляет интерфейс в виде SQL.
Если у вас большой проект то вам в любом случае приведется писать класс или набор функций для работы с файлами т.е. реализовывать некую свою СУБД. В случае с SQLite это уже готово. И какой бы заказчик не был упертым, тот факт что SQLite всего лишь прослойка между файлами и вами как программистом не оспоришь. Можно не говорить он не как о субд а об одном из расширений php как например cUrl или iconv. Короче ссыте в уши заказуну. Иначе ваш заказ можно сравнить с заказом дышать под водой без соответствующих приспособлений за любые деньги не сможете.
Спустя 10 минут, 20 секунд (5.06.2011 - 23:37) Faantoom написал(а):
fallow, я даже не представляю себе, с какой стороны к этому подойти) Писал несколько механизмов на PHP, но при большом количестве записей в БД затраты ресурсов сервера не оправдывают возможностей(( И скорость доступа к данным записанным в конце файла уж очень маленькая...
Basili4, проект действительно большой, и судя по всему перспективный.
Ну а в общем ясно....) Ща попробую что-то сделать с SQLite... Авось прокатит =)
Но вопрос всё еще остаётся открытым))
Basili4, проект действительно большой, и судя по всему перспективный.
Ну а в общем ясно....) Ща попробую что-то сделать с SQLite... Авось прокатит =)
Но вопрос всё еще остаётся открытым))
Спустя 1 минута, 42 секунды (5.06.2011 - 23:39) Arni написал(а):
Я тоже за SQLite , разница между сервером базы данных и этм в том, что с SQLite работаеш на прямую а не через сетевой интерфейс. Отсюда и прирост.
Спустя 49 секунд (5.06.2011 - 23:40) waldicom написал(а):
Faantoom
Вы действительно думаете, что Вы в нормальные сроки напишите свою СУБД на файлах, которая будет удовлетворять желаниям заказчика (см. первый пост)?
Вы действительно думаете, что Вы в нормальные сроки напишите свою СУБД на файлах, которая будет удовлетворять желаниям заказчика (см. первый пост)?
Спустя 6 минут, 19 секунд (5.06.2011 - 23:46) Faantoom написал(а):
waldicom, не думаю) тем более, тут нужна не совсем СУБД. В основном необходимо только чтение из базы, а запись можно осуществлять и вручную.
Я бы с удовольствием использовал мускул, но у заказчика свои тараканы в голове =)
В общем из всех постов я понял, что оптимальное решение - SQLite. Ну чтож, будем пробовать =)
Спасибо всем кто откликнулся.
Я бы с удовольствием использовал мускул, но у заказчика свои тараканы в голове =)
В общем из всех постов я понял, что оптимальное решение - SQLite. Ну чтож, будем пробовать =)
Спасибо всем кто откликнулся.
Спустя 2 минуты, 34 секунды (5.06.2011 - 23:49) waldicom написал(а):
Интересно было бы узнать, чем заказчик мотивирует свое желание не использовать СУБД... Расскажите?
Спустя 7 минут, 26 секунд (5.06.2011 - 23:56) Basili4 написал(а):
а сервер виндовс ??
Спустя 3 минуты, 1 секунда (5.06.2011 - 23:59) Faantoom написал(а):
waldicom, Чесно говоря я не целиком в теме, но про субд заказчик и слышать не хочет.
Я так понимаю, он хочет чтобы база была портативной, то есть можно было хранить её на сьёмном носителе, а также редактировалась обычным текстовым редактором. В подробности я не вникал.
Basili4, да, windows. Причём допускается использование абсолютно любой версии.
Я так понимаю, он хочет чтобы база была портативной, то есть можно было хранить её на сьёмном носителе, а также редактировалась обычным текстовым редактором. В подробности я не вникал.
Basili4, да, windows. Причём допускается использование абсолютно любой версии.
Спустя 8 минут, 41 секунда (6.06.2011 - 00:08) VELIK505 написал(а):
| Цитата (Faantoom @ 5.06.2011 - 20:59) |
| waldicom Я так понимаю, он хочет чтобы база была портативной, то есть можно было хранить её на сьёмном носителе, а также редактировалась обычным текстовым редактором. |
Проект будет большой?
SQLITE только для мелких сайтов, для больших плохо
Можно сделать на файлах и передавать в memcached а там уже сколько выделишь под него оперативы столько и будет жрать
Спустя 7 минут, 23 секунды (6.06.2011 - 00:15) Basili4 написал(а):
Faantoom
| Цитата (Faantoom @ 6.06.2011 - 00:59) |
| , а также редактировалась обычным текстовым редактором |
| Цитата (Faantoom @ 5.06.2011 - 23:03) |
| Хранение огромного количества информации |
противоречия я мало понимаю в устройствах БД но могу сказать что СУБД настолько быстры потому что хранят индексы. так вот если ты напишешь код который будет работать по представленным тебе требованиям. ты по любому будешь использовать свои велики для создания индексов. + еще различные механизмы сериализации данных жизни тебе портить будут. Короче тут только и выбить блаж из головы заказчика и про вынь сервера тоже. Тоже мне придумали огромный массив и без СУБД куда катится мир. Пойду свечку поставлю за здоровье своих заказунов (им голову такое не лезет)
Спустя 7 минут, 46 секунд (6.06.2011 - 00:23) Faantoom написал(а):
Короче ясно =) я так понял, самым лучшим решением будет убедить заказчика использовать мускул))
Ну попытаемся =))
Ну попытаемся =))
Спустя 2 часа, 50 минут, 47 секунд (6.06.2011 - 03:14) Invis1ble написал(а):
Я как-то пробовал написать велик тупо на текстовых файлах... Короче спустя где-то неделю неудачных попыток я понял что это бред и оптимальней делать с использованием SQLite
Спустя 6 часов, 49 минут, 29 секунд (6.06.2011 - 10:03) LRCenter написал(а):
Faantoom
Позвольте полюбопытствовать: большой объем данных это сколько?
Файлы + СУБД интерфейс на php имеет смысл использовать при размере таблицы(текстового файла) до 100-150мб, при средней дискретности информации до 100.000 объектов(строк). Это для сервера средней конфигураци на виртуальном хостинге. Потом начинаются проблемы.
Отдельный геморрой с транзакциями и записью на больших объемах. Но это решаемо.
Возьмите за основу csv. Этот формат можно редактировать в обычном редакторе электронных таблиц.
Вот вам пример работы такой СУБД, функция выборки в моем велосипеде:
http://phpforum.ru/index.php?showtopic=44603&hl=
Проблема "файловых" СУБД в парадигме чтения текстовых файлов:
Позвольте полюбопытствовать: большой объем данных это сколько?
Файлы + СУБД интерфейс на php имеет смысл использовать при размере таблицы(текстового файла) до 100-150мб, при средней дискретности информации до 100.000 объектов(строк). Это для сервера средней конфигураци на виртуальном хостинге. Потом начинаются проблемы.
Отдельный геморрой с транзакциями и записью на больших объемах. Но это решаемо.
Возьмите за основу csv. Этот формат можно редактировать в обычном редакторе электронных таблиц.
Вот вам пример работы такой СУБД, функция выборки в моем велосипеде:
http://phpforum.ru/index.php?showtopic=44603&hl=
Проблема "файловых" СУБД в парадигме чтения текстовых файлов:
| Цитата |
| Некоторые операции с текстовыми файлами чрезвычайно неэффективны. Например, если в файле встретится число, машина должна будет перевести его в свой внутренний формат, вызвав (сравнительно) сложную процедуру конвертации числа. Чтобы перейти на 1000-ю строку, требуется считать 999 строк, идущих до неё. Сложно заменить одну строку другой, и т. д. Поэтому при работе с большими объёмами данных текстовые файлы применяют только как промежуточный формат, обеспечивающий интероперабельность. |
Спустя 3 часа, 24 минуты, 3 секунды (6.06.2011 - 13:27) Faantoom написал(а):
LRCenter
Ожидаемый обьём базы данных - от 200 до 500 тысяч строк, длина каждой строки фиксированная - 100 символов. Строка не разбита на элементы (ячейки), то-есть считывать нужно сразу все 100 символов, не выделяя из неё элементы. Поэтому в таблице нет необходимости.
Пример формата базы данных:
Ожидаемый обьём базы данных - от 200 до 500 тысяч строк, длина каждой строки фиксированная - 100 символов. Строка не разбита на элементы (ячейки), то-есть считывать нужно сразу все 100 символов, не выделяя из неё элементы. Поэтому в таблице нет необходимости.
Пример формата базы данных:
0iwh013ufh0iuhpefhfhoiuwfe98uyg12oyg9o76qfygtvkqhvf9i7q3fhbqvlehfgo8qjhbvcnbda313bljqbflqe13r13lbws0А за Ваш пример огромное спасибо, появились кое-какие идеи...
0dahpvifqyue8fgoqegofluyqscnbasdkfuyqto8fu7towqibfewfiuefy0p198flij1hgbelfigpfiugpquewfpipugblfiqwg0
Спустя 1 час, 18 минут, 52 секунды (6.06.2011 - 14:46) LRCenter написал(а):
Faantoom
Ну вот с переносом строки давайте считать - 102байта(\r\n) x 500.000(считаем по максимуму) получается (51 000 000/1024)/1000~50Мб. Это ерунда. Тем более выборки по параметрам нет, просто чтение строки. Правда строк многовато. Надо пробовать, короче.
Я тут CMS-ку разрабатываю с единомышленниками на основе самописной файловой СУБД. В конце лета-начале осени должна быть готова. Как раз особое внимание стараюсь уделить производительности. Я понял что тягаться с SQL в плане производительности на огромных объемах, бесполезно. Но на малых и средних объемах данных(не превышающих вышеуказанные характеристики) - производлительность вполне сопоставимая, и есть ряд приемуществ, так что овчинка точно стоит выделки, ведь для 95% сайтов достаточно мощности файловых СУБД.
Сообщу вам в личку как закончим, если вам интересно.
Ну вот с переносом строки давайте считать - 102байта(\r\n) x 500.000(считаем по максимуму) получается (51 000 000/1024)/1000~50Мб. Это ерунда. Тем более выборки по параметрам нет, просто чтение строки. Правда строк многовато. Надо пробовать, короче.
Я тут CMS-ку разрабатываю с единомышленниками на основе самописной файловой СУБД. В конце лета-начале осени должна быть готова. Как раз особое внимание стараюсь уделить производительности. Я понял что тягаться с SQL в плане производительности на огромных объемах, бесполезно. Но на малых и средних объемах данных(не превышающих вышеуказанные характеристики) - производлительность вполне сопоставимая, и есть ряд приемуществ, так что овчинка точно стоит выделки, ведь для 95% сайтов достаточно мощности файловых СУБД.
Сообщу вам в личку как закончим, если вам интересно.
Спустя 1 час, 3 минуты, 2 секунды (6.06.2011 - 15:49) Faantoom написал(а):
LRCenter, интересно конечно! Если действительно ваша СУБД будет соответствовать указанным выше параметрам, могу её приобрести.
Спустя 48 минут, 35 секунд (6.06.2011 - 16:38) LRCenter написал(а):
Хорошо, только она скорее всего будет распространятся по лицензии MIT, т.е. даром даже для коммерческих проектов. Обязательно сообщу вам по появлении протестированнной, полностью работоспособной версии
Спустя 21 минута, 10 секунд (6.06.2011 - 16:59) Faantoom написал(а):
LRCenter, ну спасибо огромное заранее
Спустя 14 минут, 5 секунд (6.06.2011 - 17:13) LRCenter написал(а):
Faantoom
Нет проблем
Параллельно вся инфа и точные сроки появятся тут http://boxseo.ru/
Надеюсь уважаемые модераторы не сочтут за рекламу.
Я ведь пока еще ничего не собираюсь продавать
Нет проблем
Параллельно вся инфа и точные сроки появятся тут http://boxseo.ru/
Надеюсь уважаемые модераторы не сочтут за рекламу.
Я ведь пока еще ничего не собираюсь продавать
Спустя 4 часа, 55 минут, 54 секунды (6.06.2011 - 22:09) Faantoom написал(а):
Ну будем ждать