,

Оптимизация хранения данных для быстрой и эффективной работы c Ofsys

11_09_13_storage_optimisation

С САМОГО НАЧАЛА РАБОТЫ С OFSYS ВАЖНО ОПТИМИЗИРОВАТЬ ХРАНЕНИЕ ДАННЫХ

Создавать новые поля и заполнять их любыми данными в Ofsys легко и удобно. Но крайне важно понимать, что скорость работы системы напрямую зависит от того, что и как Вы храните в базе Ofsys. Это особенно важно, если Вы отправляете большое количество сообщений, содержащих данные из реляционных таблиц и сложные запросы. Поэтому если с самого начала Вы оптимизируете хранение данных, скорость работы часто используемых функций (создание сообщений, отправка кампаний, поиск) всегда будет максимальной.

ВЫБОР МЕЖДУ ТЕКСТОВЫМ И ЧИСЛОВЫМ ФОРМАТОМ ( TEXT VS INTEGER)

Запомните:
Число = 4 байта
Текст = 2 байта/ 1 символ (Юникод)
Как Вы видите, формат данных важен. Всегда отдавайте предпочтение числовым значениям, а не текстовым!
Например, если Вы используете поле Source для указания источника регистрации контакта, присвойте “1” всем зарегистрировавшимся на сайте, “2” – зарегистрировавшимся на Facebook и т.д. вместо значений “Web registration”/ “FB registration”. В этом случае, ресурсы на обработку таких данных будут минимальны.
Другой пример. Допустим, у Вас есть поле “Auth” , содержащее уникальный токен для каждого контакта, для авторизации на сайте. Иногда мы видим такие значения в этом поле: 146da4c96ade57c231d795a589b3b48e (32 символа!).
32 символа Х 2 байта это уже 64 байта.
64 байта Х количество контактов в базе ( например, 2 миллиона) = 140 мегабайт.
В реальности, вероятность умышленного подбора токена из 32 знаков ничтожна: 1 из 6232. (представьте значение из “2” и 57 нулей после!). То есть нет никакой необходимости генерации и передачи в Офсис таких значений! Согласитесь, вполне достаточно использовать 8-значные токены для того, чтобы иметь вероятность подобного события: 1 из 218340105584896.
А объем хранимых данных для этого поля тогда сократится с 140 до 30 Мб. В случае же использования только числовых значений – до 8 Мб, а вероятность подбора – 1 из 4 млрд. Подобный пример наглядно демонстрирует возможность оптимизации без ущерба безопасности Ваших данных!

ВЫБОР МЕЖДУ ЧИСЛОВЫМ ЗНАЧЕНИЕМ И “TRUE/FALSE” ( BOOL VS INTEGER)

Если значение в поле может быть логически описано условием ” Истина/ Ложь”, всегда выбирайте формат True/False, а не Number – Integer с последующим присвоением значения 1/0.
Например, в Вашей базе есть 3 поля “isPromoCodeUser” , “IsGoodName”, ” IsProductInBasket ” c форматом Integer, которые содержат только 2 возможных значения (да/нет): 1 или 0. Посчитаем объем, занимаемый данными в этих полях:
12 байт Х 2 млн контактов = 26,7 Мб.
В случае использования формата True/False занимаемый объем будет всего 2,5 Мб.

УДАЛЯЙТЕ НЕИСПОЛЬЗУЕМЫЕ ПОЛЯ

Каждое пустое неиспользуемое поле – это 4 байта в SQL таблице Ofsys. Если в Вашей базе контактов 10 пустых полей, мы снова получаем сотни лишних мегабайт!

НИКОГДА НЕ ХРАНИТЕ HTML БЛОКИ В ПОЛЯХ OFSYS!

Внимание! В нашей системе это запрещено! Мы оставляем за собой право ограничить доступ или блокировать Ваш аккаунт до тех пор, пока поля не будут полностью очищены от html -блоков.
Таким образом, оптимизация и грамотная работа с данными в Ofsys позволит сократить объем Вашей базы на 75%.Ofsys будет работать быстрее, а Ваша работа с Ofsys будет комфортной и эффективной!

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply