Исправление Kroz, (текущая версия) :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? А если у вас не всё хорошо с процессами, то и на дни. Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…
Итог: если вашим клиентам нужен банальный std::unordered_set<std::string> и небольшое количество данных, то они могут реализовать его сами у себя в коде. Если задача такова, что рассматривается вариант создания отдельного приложения, то года через 2 у вас появится либо 1) седые волосы, либо 2) замечательный опыт создания второго Redis’а, а также работа с которой вас не смогут уволить.
Исправление Kroz, :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? А если у вас не всё хорошо с процессами, то и на дни. Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…
Итог: если вашим клиентам нужен банальный std::unordered_set<std::string> и небольшое количество данных, то они могу реализовать его сами у себя в коде. Если задача такова, что рассматривается вариант создания отдельного приложения, то года через 2 у вас появится либо 1) седые волосы, либо 2) замечательный опыт создания второго Redis’а, а также работа с которой вас не смогут уволить.
Исправление Kroz, :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…
Итог: если вашим клиентам нужен банальный std::unordered_set<std::string> и небольшое количество данных, то они могу реализовать его сами у себя в коде. Если задача такова, что рассматривается вариант создания отдельного приложения, то года через 2 у вас появится либо 1) седые волосы, либо 2) замечательный опыт создания второго Redis’а, а также работа с которой вас не смогут уволить.
Исправление Kroz, :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…
Итог: если вашим клиентам нужен банальный std::unordered_setstd::string и небольшое количество данных, то они могу реализовать его сами у себя в коде. Если задача такова, что рассматривается вариант создания отдельного приложения, то года через 2 у вас появится либо 1) седые волосы, либо 2) замечательный опыт создания второго Redis’а, а также работа с которой вас не смогут уволить.
Исправление Kroz, :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…
Итог такой: если вашим клиентам нужен банальный std::unordered_setstd::string и небольшое количество данных, то они могу реализовать его себе в коде, и периодически сбрасывать на диск. Если задача такая что они рассматривают вариант отдельно приложения, то года через 2 у вас появится либо 1) седые волосы либо 2) замечательный опыт создания второго Redis’а и работа с которого вас не смогут уволить.
Исходная версия Kroz, :
Эти вопросы уже на тему «не взять ли вам что-то нормальное, над чем 10 лет работало 70 человек до вас»
Нет. Это ответ на этот вопрос:
Потому как Вы не до конца понимаете что Вас ждёт, буквально, «прямо за углом».
Если б понимал, то наверное не задавал эти все вопросы.
На всякий случай уточню: у вас Kubernetes?
Теперь по вашим комментариям.
Как вы планируете решать split-brain проблему? Если что это ситуация когда две реплики (у вас же high availablilty, так?)
Нет. В задаче не было.
Ок, тогда уточню: ваши клиенты ок с тем, что иногда вас сервис будет пропадать на часы (downtime)? Объяснять почему?
Как вы планируете решать проблему миграции данных, когда при очередном апгрейде придётся поменять дата-схему?
Если речь про вариант (1), то никак. Если очень надо, то кодить на С++ конвертер данных и т.п. гимор. Этим (2) и хорош - alter table просто.
То есть CI/CD у вас нет? А как доставляются патчи, в частности баг-фиксы? Люди ручками скачивают с репы, делают теми же ручками ALTER TABLE и запускают апгрейд? Сколько планирует пользователей вашего движка через 5 лет?
Ваш C++ фреймворк умеет в бекапы? И как это будет работать если параллельно с бекапом кто-то будет добавлять/изменять/удалять записи?
Там просто снепшоты, например. Любой файл на диске без суффикса .inprogress в имени - можно просто взять и унести в бекап. А бекап WAL - это просто его инкрементальное копирование в бекапилку (или другую реплику). Это как раз не самая сложная часть.
Какой может быть максимальный объем данных? Учитывая что были разговоры про масштабируемость, предположу что могут быть гигабайты. Как вы планируете делать INSERT, DELETE? Если реально вставлять и удалять записи, то у случае такой операции на первой записи вам потребуется перезаписать весь файл (что при таких объемах займёт значительное время, но допустим вы обойдёте это асинхронностью). И, если параллельно с перезаписью файла бежит бекап, то он, бекап, превратится в тыкву. Понятно почему? А если вы удаляете путём дописывания в файл или другой модификации без изменения размера, то 1) вам потребуется VACUUM механизм 2) время поиска может быть уже не миллисекунды; и это всё ещё без JOIN’ов.
По поводу документации, поддержки и т. п. - сразу ответьте на вопрос: вы хотите чтобы проект жил более 3-5 лет. Если нет, то, да, можно об этом не заморачиваться. Но если не планируется через 3-5 лет менять на что-то другое, даже банальный одностаничник требует документации. Можете не верить, но тогда запишите вот этот мой коммент, и поставьте напоминалку через 5 лет. Я гарантирую, что те люди которые еще будут за это отвечать, либо 1) давно уже заменят ваше творение на что-то другое, либо 2) будут регулярно поминать вас в суе.
Про перформанс могу набросать сценариев, но коммент и так длинный…