Форумы портала PHP.SU

PHP.SU

Программирование на PHP, MySQL и другие веб-технологии

PHP.SU Портал

Главная

Помощь

Поиск

Поиск Яндекс Вакансии

Пользователи

Здравствуйте, Гость

( Вход · Регистрация · Правила форума )

Забыли пароль?

Форумы портала PHP.SU » Список сообщений, автором которых является Nosferatu

Страниц (1): [1]

Найдено сообщений: 4

Nosferatu	Отправлено: 19 Июля, 2011 - 21:24:53 • Тема: как работает memcached • Форум: Хранение данных, их вывод и обработка
Ответов: 1 Просмотров: 1156	CTAPu4OK пишет: Нужна информация о том, как работает memcached с базой данных. Если кратко, то не как она не работает с БД. 1. Нет.(Если конечно сам туда не запишешь при кешировании) 2. Для всех глобально.

Nosferatu

Отправлено: 11 Июля, 2011 - 21:24:56 • Тема: Есть проблема хранения 3000 переменных • Форум: Хранение данных, их вывод и обработка

Ответов: 11
Просмотров: 2795

Сам задал вопрос сам на него и отвечу. Радость

По скорости работы получается так.
Быстрее
5 – массив с настройками собирается силами PHP при получение ответа от БД
4 – Требуется собирать разбирать строку в массив с настройками.
2-3 – нету простого способа работы с данными.
1 – сериализация-десерилизация данных.
Медленее.

По занимаемому месту в БД
Меньше
2-3 – Биты
5 – биты + нагрузка на создание ячеек.
4 – текстовая строка. ~3кб
1 – сериализованные данные. Больше 168 кб. 
Больше

В итоге первоначальная идея с сериализваным массивом, оказалась самой медленным и прожорливым решением. Разочарован очень сильно.

Нормального решения обработать пункты 2-3, силами PHP, нет. Более того оно ограничено 32 битами.

Решение с хранением в строке, хорошее, но проигрывает чуть-чуть решению с массивом.

Если посмотреть в первое сообщение, то можно заметить что решение использовать БД, пришло в самый последний момент. Тем не менее, остановился на нём.

DeepVarvar
Использовать MemCache для кеширования настроек которые будут использованы один раз в начале рабочей недели. Выглядит как минимум "странно". Ха-ха

Использование MemCache более оправдано, в случае с часто запрашиваемыми данными.

RomAndry
А я то думал реляционные базы всех победили, а нет конкуренты ещё есть...
Спасибо, на будущее обязательно познакомлюсь с решениями NoSql.

Мелкий
Спасибо, почитал. Это как то маловато. Если не ошибаюсь то PHP нет возможности объявить двоичное число. Ну и 32 бита в моём случае совсем не помогут.

Я остановился на варианте 5. Но если у кого будут интересные предложения, за исключением выбрать лучший движок/настроить БД/ использовать полезности/купить мощный сервак, то будут рад почитать.

Nosferatu

Отправлено: 10 Июля, 2011 - 19:32:37 • Тема: Есть проблема хранения 3000 переменных • Форум: Хранение данных, их вывод и обработка

Ответов: 11
Просмотров: 2795

OrmaJever пишет:

Мне кажется лутше всего хранить в масиве и не замарачиватся, но если значения могут быть только 0 или 1 то можно зделать одно число (как последовательность бит)

Спасибо за попытку, но не помогло. Написало что "Warning: Cannot use a scalar value as an array in index.php on line 40 "

Идиальный вариант это использовать строку битов, и проводить все манипуляции с ними. Считаю этот вариант самым лучшим как по скорости так и по объёму используемой памяти, но к сожалению возможности работы PHP с бинарными данными нету. Растерялся

White
Почти полностью согласен. Можете аргументировать позицию почему 5 самый медленный и требовательный??? Однако

У меня есть предположения, но хотелось бы знать ваше мнение.

Craken
Читайте внимательнее. 3000 переменных-настроек, а не строк.
Строк там будет over 9000. Радость

Соответственно не о какой таблице в 3000 столбцов речи идти не может.
Почему вариант 5??? Считаю что SQL серверу проще будет отдать одну большую ячейку, чем 1000 маленьких. Разве это не так??? Не понял

Nosferatu

Отправлено: 10 Июля, 2011 - 13:28:03 • Тема: Есть проблема хранения 3000 переменных • Форум: Хранение данных, их вывод и обработка

Ответов: 11
Просмотров: 2795

Здравствуйте. Мне очень необходима помощь знающих людей.

Есть проблема хранения 3000 переменных, каждая переменная принимает значение 0 или 1. Данные настройки хранятся в БД.

Я додумался до четырёх решений.
1. Хранить всё как элементы в Массива, серилизовать, сжимать и хранить в БД как текст.
2. Хранить всё как Бинарное число. Редактировать как не знаю.
3. Хранить как Десятичное число. Редактировать как не знаю.
4. Хранить как Строку. Редактировать как строку.
5. Хранить каждую переменную отдельно в БД.
Смог реализовать первый вариант, но получилась строка в 6000 символов. Это очень много, если учесть что первоначально переменных 3000. Первый реализованный вариант мне не нравится, хоть он и является очень простым для работы.

Могли бы вы подсказать более быстрые и меньшие по размеру решения?
Пожалуйста, оцените решения по скорости работы и по количеству занимаемого места.

Страниц (1): [1]