Как получить доступ к AWS дискам вне инстанса?

А прицепить диск как-то к S3 для доступа через ВЕБ-морду какую-то, не получится?

Что есть AMI - если не сложно? Если это проще, то лучше так =)

Существуют ли быстрые способы сериализации/десериализации объектов?

Adamos, что за транспортный объект? и в каком смысле "таки JSON"?

Существуют ли быстрые способы сериализации/десериализации объектов?

msgpack - там приведен бенч, он проигрывает по скорости JSON-у "из коробки"...
bson - пока не нашел сравнительных тестов, чтобы понять

спасибо =)

Существуют ли быстрые способы сериализации/десериализации объектов?

да я тоже думаю над кастомным решением, начал делать для проверки - по размерности получается существенно меньше JSON-ов... размерность только для строковых значений и ключей к сожалению, не меняются - но это в принципе ожидаемо...

накидаю для тех типов, которые летают по протоколу, попробую какие-нибудь бенчмарки сварганить на маленьких/средних/больших объектах для сравнения скорости упаковки/распаковки...

Как оптимально выстроить хранение данных?

fogree, да там не только место, там еще и с индексами получается "застрелиться"...

Как оптимально выстроить хранение данных?

sim3x, деталей и не предоставлю. Но не понимаю, каких таких данных не хватает?
Ну давайте отталкиваться от ситуации:

вариант 1:
- одна таблица: id / uid / str1 / str2 / str3 / in1 / int2 / int 3

вариант 2:
- четыре таблицы:
- id / uid
- id / uid / str1 / int1
- id / uid / str2 / int2
- id / uid / str3 / int3

результат должен быть по правилу, выводить поле "справа" (т.е. если заполнено 3, то 1 и 2 неважно), т.е. каждый запрос формирует итог по результату из всех 4-х

вариант 3:
- четыре таблицы с реализацией логики:
- id / uid / str0 / int0
- id / uid / str1 / int1
- id / uid / str2 / int2
- id / uid / str3 / int3

выборка только из главной, а данные там обновляем при изменении записей в "дочерних"

Вопрос соответственно звучит так - какой из вариантов будет наиболее оптимальным как с точки зрения выборок (основная часть) - которые должны быть быстрыми, так и с точки зрения изменения (их меньше, но тоже хватает) - которые тоже желательно делать не по 10-15-20 секунд

Как оптимально выстроить хранение данных?

sim3x,

Что хранится - данные всякие в цифирках и строчках (имена/пароли/явки)
Зачем в БД - ну наверное, потому что по файлам делать выборки сложнее (тем более разными сервисами обработки на разных железяках по сети)

Не в обиду, но вопрос странный... может уточните, что имеете ввиду?

Как понять причину поведения выборки в MongoDB?

Для первого "быстрого":

...
        "winningPlan" : {
            "stage" : "FETCH",
            "filter" : {
                "update" : {
                    "$gt" : ""
                }
            },
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "sort" : -1
                },
                "indexName" : "_sort_",
                "isMultiKey" : false,
                "multiKeyPaths" : {
                    "sort" : []
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "sort" : [ 
                        "[MaxKey, MinKey]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ 
            {
                "stage" : "SORT",
                "sortPattern" : {
                    "sort" : -1.0
                },
                "inputStage" : {
                    "stage" : "SORT_KEY_GENERATOR",
                    "inputStage" : {
                        "stage" : "FETCH",
                        "inputStage" : {
                            "stage" : "IXSCAN",
                            "keyPattern" : {
                                "update" : 1
                            },
                            "indexName" : "_update_",
                            "isMultiKey" : false,
                            "multiKeyPaths" : {
                                "update" : []
                            },
                            "isUnique" : false,
                            "isSparse" : false,
                            "isPartial" : false,
                            "indexVersion" : 2,
                            "direction" : "forward",
                            "indexBounds" : {
                                "update" : [ 
                                    "(\"\", {})"
                                ]
                            }
                        }
                    }
                }
            }
        ]
...

Для второго "медленного":

...
        "winningPlan" : {
            "stage" : "SORT",
            "sortPattern" : {
                "sort" : -1.0
            },
            "inputStage" : {
                "stage" : "SORT_KEY_GENERATOR",
                "inputStage" : {
                    "stage" : "FETCH",
                    "inputStage" : {
                        "stage" : "IXSCAN",
                        "keyPattern" : {
                            "update" : 1
                        },
                        "indexName" : "_update_",
                        "isMultiKey" : false,
                        "multiKeyPaths" : {
                            "update" : []
                        },
                        "isUnique" : false,
                        "isSparse" : false,
                        "isPartial" : false,
                        "indexVersion" : 2,
                        "direction" : "forward",
                        "indexBounds" : {
                            "update" : [ 
                                "[\"\", \"\"]"
                            ]
                        }
                    }
                }
            }
        },
        "rejectedPlans" : [ 
            {
                "stage" : "FETCH",
                "filter" : {
                    "update" : {
                        "$eq" : ""
                    }
                },
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "sort" : -1
                    },
                    "indexName" : "_sort_",
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "sort" : []
                    },
                    "isUnique" : false,
                    "isSparse" : false,
                    "isPartial" : false,
                    "indexVersion" : 2,
                    "direction" : "forward",
                    "indexBounds" : {
                        "sort" : [ 
                            "[MaxKey, MinKey]"
                        ]
                    }
                }
            }
        ]
...

Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

Philipp, сравнение "не false" - это очень редкая операция в принципе, постоянная операция сравнения как раз $gt и $lt - т.к. в поле некое подобие групповой сортировки что ли... Ну т.е. там пишется что-то типа "se032-dr-230-12/3442" - т.е. по сути поле заполняется по определенному строковому шаблону - который при сравнении как раз и получается что увеличивается, по нему и сортировку делают и отборы часто....

Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

caballero, кто ж мне бесплатно даст МсСкл или Оракл =))) да и сомневаюсь я, что постгре по сравнению с ним не конкурент... да и таблицы в 50 лямов записей (в перспективе) как-то не тянут на мегаогромные

Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

Мигрировал коллекцию из монги на постгре и попробовал выполнить базовые запросы (нужные индексы построил) - как-то нерадужно. То, что на монге выдает данные за доли секунды, на постгре выполняется за почти 2 сек...
По сути ничего сложного нет и никаких связей тоже, все в одной табличке, прямым сравнением - просто таблица в 10млн записей...
Это как-то "обидно" что ли...

Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

Philipp последовал вашему совету, но видимо не совсем верно. Использовал значение false для поля "без данных" (типа - не существует), а при заполнении в поле пишется строковое значение. Скорость увеличилась, индекс построился... Но тут словил одну непонятную ситуацию...
1. find({'field':false}) - быстро
2. find({'field':{$ne: false}}) - полный тухляк
3. find({'field:{$gt:''}}) - быстро

По полю делал индексы и прямой и обратный, ситуация не изменилась. Все три варианта используют индекс.

Просто непонятно, почему прямое сравнение === false выполняется быстро, а обратное по сути !== false умирает минуту (дальше просто терпение лопнуло)... Есть идеи?

Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

Да я чую, что именно это и нужно делать... Давно знакомый мускуль сразу правда, приходится отсекать, ибо помнится был опыт работы и таблицы с 1-2млн записей тормозили нещадно, а тут ожидается со временем наполнение под 100млн...
Хотя потянет ли постгре такие таблички или придется подумать хорошенько на тему партиций =(((

Как встроить страницу Youtube в сайт?

Nikolay Petyukh, такие как ты мне часто говорили "никогда" и "забудь"... Самое смешное было потом смотреть на их физиономии.
А твое кредо по жизни, судя по всему, все забывать ;)

Callback / Promises / await - что быстрее и экономичнее?

Дмитрий Макаров, да кто ж против-то =))) по хорошему некоторые части вообще стоит переделать целиком и желательно на другом языке, поддерживающем многопоточку + асинхронку - но пока для таких глобальных переделок времени нет - начинать приходится с малого...

Callback / Promises / await - что быстрее и экономичнее?

Leo Developer, понял, значит лучше через конструктор, спасибо еще раз!!!

Callback / Promises / await - что быстрее и экономичнее?

Leo Developer, а вот тоже вопросец, вариант "создания алиаса" в конструкторе + указание этого алиаса в качестве колбека, можно ли заменить на прямое указание с bind(...)?

Ну т.е. использовать сразу:
this.asyncFn(v, this.asyncRes.bind(this));

Это будет по факту "созданием одноразовой функции" или нет?

Callback / Promises / await - что быстрее и экономичнее?

Антон Швец, да переписывать-то все-равно придется =)))

Callback / Promises / await - что быстрее и экономичнее?

Вот спасибочки, а то я уже всю голову сломал, как передавать метод-обработчик в качестве функции колбека так, чтобы не было созданий этих анонимок-коротышей...
Текущий код вообще реализован в таком формате, что в замыканиях не только рабочие переменные, и они же передаются в параметризации колбеков, но и создается постоянно "алиас"-замыкание... и вот представляете, что там происходит, когда идет вызов data() десятки тысяч раз в секунду, тогда как примерное время выполнения с "входа до выхода" около 2-3х секунд (соответственно столько времени живут все эти замыкания и вновь создаваемые функции со всеми вытекающими последствиями в том числе у мусорщика)...

data(v1, v2) {
  const self = this;
  ...
  this.asyncFn(v1, v2, function(res) {
    self.asyncRes(v1, v2, res);
  });
  ...
};

Callback / Promises / await - что быстрее и экономичнее?

эмммм, точно именно так? или имя "алиаса" нужно другое задать и потом его юзать?

class CLS {
  constructor() {
    this.asyncResBind = this.asyncRes.bind(this);
  };
  ...
  data(v1, v2) {
    ...
    this.asyncFn(v, this.asyncResBind);
    ...
  };
};