Пасечник Кузьмич

Насколько я понял, вы пытаетесь опрашивать базу данных и выводить изменения, а BSession.GetData() как раз данные из базы получает с помощью SQLAlchemy.

Во-первых, обращение к базе синхронное и в моменты выполнения запросов будет ставить колом все установленные websocket-соединения. Использовать для решения это проблемы можно sqlalchemy_aio или SQLAlchemy+aiopg. А ещё лучше asyncpg без SQLAlchemy.

Во-вторых, чтобы пользователи не получали каждый раз всё содержимое базы, стоит хранить где-нибудь последний извлечённый id и запрашивать из базы только записи, у которых id больше.

Наконец, что касается организации двусторонней асинхронности, должен помочь немного модифицированный вариант из документации:

async def consumer_handler(websocket, path):
    while True:
        message = await websocket.recv()
        # делаем что-нибудь с сообщением от клиента


async def producer_handler(websocket, path):
    while True:
        data = await BSession.GetData()
        if data:
            await websocket.send(data)


async def handler(websocket, path):
    consumer_task = asyncio.ensure_future(consumer_handler(websocket))
    producer_task = asyncio.ensure_future(producer_handler(websocket))
    done, pending = await asyncio.wait(
        [consumer_task, producer_task],
        return_when=asyncio.FIRST_COMPLETED,
    )

    for task in pending:
        task.cancel()


loop = asyncio.get_event_loop()
loop.run_until_complete(websockets.serve(handler, 'localhost', 8765))
loop.run_forever()

create table categories (
  id integer primary key,
  parent integer references categories,
  name varchar(50) not null
);

create table manufacturers (
  id integer primary key,
  name varchar(30) not null
);

create table goods (
  id integer primary key,
  category integer references categories,
  manufacturer integer references manufacturers,
  name varchar(50) not null
);

select
  m.name,
  count(*) as goods_count
from goods as g
inner join manufacturers as m
  on g.manufacturer = m.id
where category = 1
group by m.name;

Живой пример в sqlfiddle

Один сегмент WAL обычно имеет фиксированный размер 16мб (опция компиляции postgresql with-wal-segsize, если вы её указывали - вы должны об этом знать, плюс она требует initdb делать заново). Поэтому их количество пересчитывается в объём банальным умножением.

Ограничить максимальный занимаемый объём wal сверху - нельзя. Такой единой гайки нет, даже если вас устраивает переход базы в readonly по достижении этого лимита. И есть довольно много гаек, которые при своём использовании могут попросить базу не вычищать старые wal ещё какое-то время.

Гайки, на которые надо обращать внимание:
wal_keep_segments - база оставляет на диске не меньше этого числа wal, что позволяет реплике штатно на некоторое время терять мастера и затем догонять
replication slots - если вы сделаете слот репликации и его никто не будет читать - база будет сохранять wal пока не закончится диск. Если вы используете слоты репликации, то у вас в мониторинге обязана быть отдельная проверка что слот вычитывается
max_wal_size - несмотря на название - объём wal, по накоплению которого происходит checkpoint. (либо по таймеру checkpoint_timeout смотря что случится раньше). Реально объём wal может быть выше, т.к. автоматический checkpoint намеренно не выполняется моментально, а размазан во времени.
min_wal_size - этот объём wal всегда будет на диске занят и будет переписываться по кругу. Как гарантия того, что на диске есть место под столько wal
archive_command - если включен и команда возвращает ненулевой статус возврата - то будет накапливать wal без ограничений. wal будут удалены (если только ещё не нужны какой из других настроек) когда archive_command получает от команды 0 код возврата.

Если не хочется много денег тратить на резерв свободного места на хороших SSD - разместите на SSD саму базу данных, а WAL перенесите (симлинком директории pg_xlog (до 10.0) или pg_wal (10.0 и выше)) на отдельные HDD. WAL пишутся строго последовательно, вполне возможно жить с WAL на механических дисках и держать хорошую нагрузку.
Плюс если работаете не с деньгами, можно сделать synchronous_commit = off. Что увеличит производительность всех пишущих транзакций. Но в случае фатального краха железа вы потеряете последние 3*wal_writer_delay транзакции (т.е. до 3*200мс = 600мс).

Если есть сомнения в безопасности - значит надо настраивать дополнительный уровень :D
AWS предоставляет два уровня безопасности в VPC :
Network ACL и Security Groups
Первые служат для ограничения доступа между подсетями, вторые - между сетевыми интерфейсами в VPC
Несмотря на то, что Между ними есть довольно сильная разница в поведении\применении (описана в таблице docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC... ) выполняют они примерно одну и ту же функцию.
Как дополнительная возможность безопасности(рекомендуемая AWS в вышеуказанной статье) - внутренний firewall вашей OS может закрыть link-local( 169.254.x.x) и трафик на первые 4 адреса вашего VPC (внутренний функционал AWS, этот трафик даже не отслеживается с помошью flow logs, не то что контролируется).

Однако же, рекомендуется firewall внутри инстанса все же настраивать соответственно вашим правилам.
Безопасности мало не бывает, а для того чтобы правила на всех слоях безопаности соответствовали - используйте IAAC.

Ах да, ответ на вопрос : Достаточно надёжны.

select
  u.*,
  group_concat(json_object('id', p.id, 'summ', p.summ, 'status', p.status)) as payments_json
from user as u
inner join payments as p
  on u.id = p.user_id
group by u.id, u.name;

select
  case 
    when char_length(some_field) > 15 then substring(some_field from 0 for 15) || '...'
    else some_field
  end
from some_table;

У макроса ns пропущена закрывающая скобка. И приведите версии зависимостей к актуальным:

(defproject spa-tutorial "0.1.0-SNAPSHOT"
  :description "FIXME: write this!"
  :url "http://example.com/FIXME"

  :dependencies [[org.clojure/clojure "1.8.0"]
                 [org.clojure/clojurescript "1.9.521"]
                 [org.clojure/core.async "0.3.442"]
                 [org.omcljs/om "0.9.0"]
                 [prismatic/om-tools "0.4.0"]
                 [http-kit "2.3.0-alpha2"]
                 [secretary "1.2.3"]]

  :plugins [[lein-cljsbuild "1.1.6"]]

  :source-paths ["src" "target/classes"]

  :clean-targets ["out/spa_tutorial" "out/spa_tutorial.js"]

  :cljsbuild {
    :builds [{:id "spa-tutorial"
              :source-paths ["src"]
              :compiler {
                :main spa-tutorial.core
                :output-to "out/spa_tutorial.js"
                :output-dir "out"
                :optimizations :none
                :verbose true}}]})

Проверил у себя, трансляция проходит нормально.

Ну и зачем эти костыли? Если вам надо получить json всех данных проекта, используйте сериализатор, как это делает сама команда dumpdata:

from django.apps import apps
from django.core import serializers

# Получаем список всех моделей всех приложений из INSTALLED_APPS
# и фильтруем django'вские
models = [model for model in apps.get_models() if not model.__module__.startswith('django')]

# Сериалзиуем в json полный QuerySet каждой модели
dump = ''
for m in models:
    dump += serializers.serialize('json', m._default_manager.all())

На developer.android.com примера нет

ага, у этих негодяев ваще ничего нет, зачем они только живут?..

Используйте рекурсивный CTE:

with recursive r as (
    select
      id, parent_id, name
    from catalog_category
    where id = 8
  union
    select
      cc.id, cc.parent_id, cc.name
    from catalog_category as cc
    join r
      on cc.parent_id = r.id
)
select id, name from r where id <> 8;

Этот запрос выбирает все категории дочерние по отношению к категории с ID = 8.