- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
rommer, ты загнался похерне. и себе и другим мозг пытаешь помять.
форумом ошибся с "быть или не быть". найми любого ламера тебе всё сделают [любой программист школьник разобьет тебе файлы по уму с минимальной нагрузкой и максимальной скоростью с учетом на рост объема инфы]
Anamnado добавил 17.12.2011 в 06:05
3. Возможно, будут сайты, на которых нету mysql, поэтолму надо обойтись файловой системой.
4. таких файлов может быть от одного до безконечности.
а если завтра война и выключат свет ?
ответ: на бумажке гвоздем царапай.
ps / чтобы дать тебе совет как бить файл надо знать досконально хранящуюся в нем информацию и алгоритмы выборки.
Что кто скажет?
что ещё останется дописать систему индексов, управление памятью, кеширование запросов и уже будет близко к простенькому аналогу mysql.
rommer, прошу прощения, не удержусь от оффтопа.
Сайты без БД, ворочащие гигабайтные файлы с данными — это что-то совсем нелепое. Химера какая-то.
1. в первую очередь основное ограничение, что скрипт этот пишется под разных пользователей, и надо чтобы они не возились с его установкой.
"Возиться" - это значит "завести БД на хостинге". А любая блондинка ныне может установить тот же Вордпресс.
(А написать скрипт, создающий таблицы с данными даже начинающему кодеру - делов на 5-10 мин.)
2. было сказано, что размер файл будет больше гига. Предлагаете все это хранить в таблице mysql?
Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места. + работа идет не совсем объёмом одновременно, а только с нужными данными.
4. таких файлов может быть от одного до безконечности.
Та же причина.
сайты, на которых нету mysql,
МуСуля на сайта и не бывает. Он бывает на хостинге. А ныне найти хостинг без базы - ещё нужно постараться.
и память поберечь
имеено на это тебе и ответил cryptex:
что б гиговые файлы целиков в память не читать
Включи наконец свой мозг - кто тебе на хостинге (на котором к тому же нет БД) выделит > гига мозгов сервера?
что ещё останется дописать систему индексов, управление памятью, кеширование запросов и уже будет близко к простенькому аналогу mysql.
файрбёрд\фокспро? ;)
Если так подумать, то сделать толково можно и на файлах. Разбить данные по группам в разные файлы (на часто используемые и нет), использовать сериализацию и тд. Удобно использовать в этом случае nosql бд типа ключ-значение, но тс уперся.
И совсем не нравится, как он выбрал самую высокую колокольню, чтобы плевать на ответивших.
Spell, можно использовать мощные готовые файловые системы, реализация которых есть на PHP. Сейчас сходу не вспомню, но к той же сифони был плагин для работы одной из них.
Но мы опять приходим к тому, что вопрос ведь не в том как это сделать на файлах. Проблема именно в том, что ТС подходит с учётом своего небольшого опыта не с той стороны.
Вопрос в том, что в рамках описанной задачи удобнее будет использовать уже готовую БД, реляционную или нереляционную - это уже отдельный вопрос. А если делать это на плейнтекст файлах - это заставит реализовывать функционал, который уже есть в "фабричных" базах данных, чтобы ворочать теми объёмами данных, которые описывает ТС.
Сколько записей?
у меня на работе БД шесть гиг, причем только цифирьки разные, т.е. по вашей структуре только поля типа 1, 3, 4.
самая большая (из сотни где-то) таблица - 2 млн записей.
и да, это в мире БД это считается небольшой, ничем не примечательной базой.
структура у ТС дерьмо. хранить метаданные вместе данными - зачем? зачем перечитывать постоянно кучу ненужной иннформации? должен быть один файл, в котором поля 1,3,4, а собственно файлы должны лежать либо все по отдельности рядом, либо в одном большом файле (уж не знаю по какой причине). в последнем случае в метафайле добавляется поле в котором записана позиция файла и, для удобства, его длина.
а чтобы поиск быстрый был, нужно к метафайлу индекс построить, какое-нибудь двоичное дерево (быстрее еще ничего не придумали), чтобы не последовательно все читать.
и в результате получаем все ту же базу данных. с одной только разницей что в текущих БД уже все это давно сделано, протестировано и сильно заоптимизировано как на скорость, так и на потребление памяти.
ТС-у - почитать как писался ибей. он тоже сначала был на пхп+файлы. когда количество аукционов достигло 50К, он просто заткнулся. пришлось срочно прикручивать БД. Либо помедитировать на тему "почему фейсбук построен вокруг MySQL, а не на чистых файлах"
и да, не нужно изобретать очередной велосипед
iopiop добавил 17.12.2011 в 22:24
Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места.
это как, БД их сжимает, что ли? ;-)
на самом деле все с точностью до наоборот, т.к. структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
Вставлю свои 5 копеек.
хранить метаданные вместе данными - зачем?
Полностью согласен, давайте для начала отделим "мух от котлет"
Файлы так файлы. Допустим.
У меня возникла следующая идейка:
Идейка, скажем так, на уровне студента первого курса, без обид.
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Тут мы приближаемся к так называемым файловым базам данных(типа Paradox, если конечно кто еще помнит :) ). Тут нужно обязательно учесть, что индекс нужно будет перестраивать и восстанавливать в случае сбоя.
Мороки конечно будет достаточно, но вполне реализуемо. Как устроены индексы я думаю понятно, в любом случае вопрос давно описан в массе литературы.
Если говорить про БД, то хранить те же файлы в самой БД не всегда целесообразно. Достаточно хранить ссылку на файл. Тут и скачка напрямую и уменьшение размера таблицы.
структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
Можно ТАК построить индексы, что скорость наоборот упадет :) Извините за оффтоп.
Так же соглашусь с тем, что найти хостинг без БД надо еще суметь. Обычно БД уже предустановлена. А далее все что нужно - сделать скрипт типа install.(php, aspx и т.п.) который всю работу по инсталляции и сделает.
Как то так.
это как, БД их сжимает, что ли? ;-)
если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.