Follow

Оптимизация базы данных для быстрой и эффективной работы c 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 или m/f.
Например, в Вашей базе есть 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 Comments

Please sign in to leave a comment.