AR
я вот, если честно, не решил хочу ли я с pgplsql связываться в анализаторе. есть шанс никогда не доделать больше ничего )
Size: a a a
2020 August 31
СА
А разве над UUID имеет смысл операция больше/меньше?
AR
А разве над UUID имеет смысл операция больше/меньше?
вы все сегодня сговорились?) (с) анекдот
uuid это 128 битный инт. с интами имеет смысл больше-меньше?
uuid это 128 битный инт. с интами имеет смысл больше-меньше?
MS
А разве над UUID имеет смысл операция больше/меньше?
AR
там есть еще варианты с неймспейсами, например. не помню версию
СА
Хм, и эти люди запрещают мне ковыряться в MongoDB!
MS
Хм, и эти люди запрещают мне ковыряться в MongoDB!
не запрещают а осуждают!
СА
Кстати, к прошлой беседе про Optane: тут бойцы из Монги попробовали Optane в режиме RAM и в режиме SSD (или, по их собственному выражению, с блочным доступом по шине памяти и по шине PCI-e), и вы не поверите, что у них получилось: https://engineering.mongodb.com/post/we-replaced-an-ssd-with-storage-class-memory-here-is-what-we-learned
AR
Кстати, к прошлой беседе про Optane: тут бойцы из Монги попробовали Optane в режиме RAM и в режиме SSD (или, по их собственному выражению, с блочным доступом по шине памяти и по шине PCI-e), и вы не поверите, что у них получилось: https://engineering.mongodb.com/post/we-replaced-an-ssd-with-storage-class-memory-here-is-what-we-learned
получилось что монге все-равно ничего не поможет? )
СА
получилось что монге все-равно ничего не поможет? )
Можно и так сформулировать)
AR
Можно и так сформулировать)
зацените какая у меня скорость чтения ))))
СА
зацените какая у меня скорость чтения ))))
Кэшируешь небось?
AR
Кэшируешь небось?
не, машин лернинг
СА
не, машин лернинг
fun getMongoDBAssesmentByAI(NLRequest: String): String {
return "MongoDB sucks"
}AR
fun getMongoDBAssesmentByAI(NLRequest: String): String {
return "MongoDB sucks"
}exactly
A
1) Х может привести к проблемам
2) отсутствие Х тоже может привести к проблемам
какой из пунктов выбирать?)
2) отсутствие Х тоже может привести к проблемам
какой из пунктов выбирать?)
есть два стула....
СА
exactly
Ну окей, вот, например, боевая задачка: сервис "отметки о прочитанном".
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
СА
Ну окей, вот, например, боевая задачка: сервис "отметки о прочитанном".
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
Вопрос на зачёт автоматом: как будем масштабировать при росте нагрузки в 2, 3 и 10 раз?
IV
Ну окей, вот, например, боевая задачка: сервис "отметки о прочитанном".
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
Сервис хранит 30 дней истории просмотров юзерами контента строками вида:
user_id int96, content_id string(10), timestamp int32
На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.
Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.
Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.
Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа? Вопрос со звёздочкой: как будем делать и хранить бэкапы?
Очень мало входных данных.
1. Почему content_id это string? Там slug?
2. Почему надо обрезать не реже чем раз в сутки?
3. Вот список content_id из 1000 элементов.. - эти 1000 элементов уникальны для каждого юзера или стандартные для всех? Эти 1000 записей новые записи или вообще любые?
4. Какие паттерны у пользователя. Какое отношение просмотренных vs. непросмотренных? Как часто требуется эта операция? Список нужен пользователю или админу?
1. Почему content_id это string? Там slug?
2. Почему надо обрезать не реже чем раз в сутки?
3. Вот список content_id из 1000 элементов.. - эти 1000 элементов уникальны для каждого юзера или стандартные для всех? Эти 1000 записей новые записи или вообще любые?
4. Какие паттерны у пользователя. Какое отношение просмотренных vs. непросмотренных? Как часто требуется эта операция? Список нужен пользователю или админу?