Перейти к содержимому


Переход SAAS на Postgresql.



Сообщений в теме: 6

#1 Analitic

    Активный участник

  • Пользователи
  • PipPipPip
  • 700 сообщений
  • Пол:Мужчина

Отправлено 29 Май 2013 - 10:45

Вниманию разработчиков! На Saas в конце июня планируется переход на Postgresql. В связи с чем, рекомендуем использовать только функции из набора sql_select, sql_query, sql_fetch_assoc, sql_insert_id и т.п. описанные в файлах mysql_connect.php и sql_functions.php. При переходе в файле config.php будет изменен параметр db_engine. Стандартные функции сохранят свою работоспособность.

Также напоминаем, что К.б. будет постепенно подключать и остальные sql базы, вплоть до подключения движка nosql. Учитывая что базы имеют различный синтаксис, рекомендованный стиль обращения к базе:
1. использовать только стандартные функции Кб.
2. если возможно использовать sql_select, вместо sql_query, то использовать именно sql_select
3. использовать простые запросы, без использования конструкций типа join, union и т.п.

Пример выборки из двух таблиц:
не рекомендуемый стиль:
$result=sql_query("SELECT a.id, b.f441 as fio FROM f_data46 a LEFT JOIN f_data48 b ON b.id=a.f776 WHERE `status`=0");
$line = sql_fetch_assoc($result);

рекомендуемый стиль:
$result=data_select_field(46, '`id` , `f776`', '`status`=0');
$line = sql_fetch_assoc($result);
$result = data_select_field(48, '`f441`', '`id`=',$line['f776']);
$row = sql_fetch_assoc($result);
$line['fio'] = $row['f441'];

В этом случае LEFT JOIN разделяется на 2 простейших запроса, что позволяет ему выполняться на любой базе, а также предоставляет возможность практически неограниченно расширять базу данных, вплоть до того что разные таблицы могут быть расположены на разных серверах.

Ваши вопросы?

#2 wondertalik

    Активный участник

  • Пользователи
  • PipPipPip
  • 1 156 сообщений
  • Пол:Мужчина
  • Город:Кривой Рог, Украина

Отправлено 29 Май 2013 - 11:18

1. Будут ли оставаться сервера c mysql?
2. Второе возможно ли будет остаться на mysql, до момента готовности перейти на postgresql?
3. Использование стандартных функций(оберток, не всегда целесообразно), особенно это важно для вычислений при отображении поля, где важно оценивать реальную нагрузку на сервер и времени выполнения вычисления.
4. Вы предлагаете разбивать многотабличные запросы на несколько простых, с точки зрения масштабируемости это конечно да. Но опять же с точки зрения балансировки нагрузки между тем же вычислением на php и бд это не всегда верное решение и приведет к увеличению требования к выделенным возможностям саас аккаунтов, переходам на более высокие тарифные планы.

Я конечно понимаю причины перехода на объектно-реаляционную бд, но простите, оставьте выбор вашим клиентам. Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?

Что скажите по поводу такого синтаксиса? То есть использования функций вида mysql_*?
$result = mysql_query($sqlQuery);
$select = mysql_fetch_assoc($result);

mysqli?

/* Select запросы возвращают результирующий набор */
if ($result = $mysqli->query("SELECT Name FROM City LIMIT 10")) {
    printf("Select вернул %d строк.\n", $result->num_rows);
    /* очищаем результирующий набор */
    $result->close();
}

Сообщение отредактировал wondertalik: 29 Май 2013 - 11:23


#3 Analitic

    Активный участник

  • Пользователи
  • PipPipPip
  • 700 сообщений
  • Пол:Мужчина

Отправлено 29 Май 2013 - 11:52

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

1. Будут ли оставаться сервера c mysql?
2. Второе возможно ли будет остаться на mysql, до момента готовности перейти на postgresql?
Да, старые клиенты, при необходимости будут располагаться на серверах с Mysql. Новые будут создаваться на PostgreSql.

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

3. Использование стандартных функций(оберток, не всегда целесообразно), особенно это важно для вычислений при отображении поля, где важно оценивать реальную нагрузку на сервер и времени выполнения вычисления.
Да. Любая обертка предоставляет плюсы, и имеет минусы (как правило в производительности). Потеря производительности минимальна (замерьте сами), плюсы огромны (безопасность из коробки, независимость от базы).

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

4. Вы предлагаете разбивать многотабличные запросы на несколько простых, с точки зрения масштабируемости это конечно да. Но опять же с точки зрения балансировки нагрузки между тем же вычислением на php и бд это не всегда верное решение и приведет к увеличению требования к выделенным возможностям саас аккаунтов, переходам на более высокие тарифные планы.
Балансировать нагрузку от PHP вообще не проблема. Просто добавляем еще один сервер, направляем часть нагрузки на него используя балансировщик. При добавлении сервера, производительность возрастает вдвое. Это касается любого более менее крупного проекта. С базой все гораздо хуже. Отсюда и появляются решения типа nosql.

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

Я конечно понимаю причины перехода на объектно-реаляционную бд, но простите, оставьте выбор вашим клиентам. Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?
Объектов тут нет, чисто процедурный стиль. Выбор оставляем: если вы уже пользуетесь MySql, и переход на PostgreSql для вас не возможен смотри пункт1.

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

Что скажите по поводу такого синтаксиса? То есть использования функций вида mysql_*?

Желательно переписать на
$result = sql_query($sqlQuery);
$select = sql_fetch_assoc($result);

mysqli?

/* Select запросы возвращают результирующий набор */
if ($result = sq_query("SELECT Name FROM City LIMIT 10")) {
	printf("Select вернул %d строк.\n", sql_num_rows($result));
}

// $result->close(); - очистка не используется, если необходимо можем добавить поддержку.

#4 Analitic

    Активный участник

  • Пользователи
  • PipPipPip
  • 700 сообщений
  • Пол:Мужчина

Отправлено 29 Май 2013 - 12:00

Просмотр сообщенияwondertalik (29 Май 2013 - 11:18) писал:

Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?
Параметр db_engine уже сейчас может содержать 'innodb' либо 'myisam', новое значение параметра скорее всего будет 'postgre'.

#5 wondertalik

    Активный участник

  • Пользователи
  • PipPipPip
  • 1 156 сообщений
  • Пол:Мужчина
  • Город:Кривой Рог, Украина

Отправлено 29 Май 2013 - 12:28

Просмотр сообщенияAnalitic (29 Май 2013 - 11:52) писал:

// $result->close(); - очистка не используется, если необходимо можем добавить поддержку.
Было бы очень хорошо.

#6 Analitic

    Активный участник

  • Пользователи
  • PipPipPip
  • 700 сообщений
  • Пол:Мужчина

Отправлено 29 Май 2013 - 13:13

Просмотр сообщенияwondertalik (29 Май 2013 - 12:28) писал:

Было бы очень хорошо.

В следующей ревизии появиться функция sql_free_result.

#7 wondertalik

    Активный участник

  • Пользователи
  • PipPipPip
  • 1 156 сообщений
  • Пол:Мужчина
  • Город:Кривой Рог, Украина

Отправлено 30 Май 2013 - 15:36

Просмотр сообщенияAnalitic (29 Май 2013 - 13:13) писал:

В следующей ревизии появиться функция sql_free_result.
Данке





Количество пользователей, читающих эту тему: 2

0 пользователей, 2 гостей, 0 анонимных