|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Когда удобнее использовать NoSQL СУБД, например документо-ориентированные как MongoDB и есть ли преимущества кроме производительности и масштабирования. На сколько просто\удобно в реальных проектах использовать туже MongoDB вместо других SQL РСУБД? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 14:58 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SlaviskesКогда удобнее использовать NoSQL СУБД, например документо-ориентированные как MongoDB и есть ли преимущества кроме производительности и масштабирования. На сколько просто\удобно в реальных проектах использовать туже MongoDB вместо других SQL РСУБД? Если не нужен ACID, то можно NoSQL. В противном случае только SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 15:50 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
mad_nazgulSlaviskesКогда удобнее использовать NoSQL СУБД, например документо-ориентированные как MongoDB и есть ли преимущества кроме производительности и масштабирования. На сколько просто\удобно в реальных проектах использовать туже MongoDB вместо других SQL РСУБД? Если не нужен ACID, то можно NoSQL. В противном случае только SQL.Хм. А мы поддержку ACID самостоятельно реализовали поверх MongoDB. Но основным хранилищем пока остаётся MS SQL Server ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 19:13 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
mad_nazgulЕсли не нужен ACID, то можно NoSQL. В противном случае только SQL. http://stackoverflow.com/questions/2608103/is-there-any-nosql-that-is-acid-compliant ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 20:50 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANA Хм. А мы поддержку ACID самостоятельно реализовали поверх MongoDB. Но основным хранилищем пока остаётся MS SQL Server Разрешите поинтересоваться в целях повышения образованности, а зачем тогда вообще связыватся с MongoDB. В минусе - зоопарк, необходимость поддержки еще одного звена и т.д. и т.п., а в плюсе? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 20:55 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
на сколько я знаю кроме ACID там полная задница с джоинами. т.е. если условия задачи изменились и тебе нужно не просто вытаскивать документ, а несколько связанных, то если это не было заложено изначально в архитектуру, то туши свет. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 23:37 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SERG1257skyANA Хм. А мы поддержку ACID самостоятельно реализовали поверх MongoDB. Но основным хранилищем пока остаётся MS SQL Server Разрешите поинтересоваться в целях повышения образованности, а зачем тогда вообще связыватся с MongoDB. В минусе - зоопарк, необходимость поддержки еще одного звена и т.д. и т.п., а в плюсе?Ну как зачем.. Performance, Scalability, and High Availability... А для кэширования мы используем Couchbase, жуть да? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 01:17 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Yo.!на сколько я знаю кроме ACID там полная задница с джоинами. т.е. если условия задачи изменились и тебе нужно не просто вытаскивать документ, а несколько связанных, то если это не было заложено изначально в архитектуру, то туши свет.Ну эту "задницу" мы обошли при помощи шаблона "прямые ручки" ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 01:18 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANAНу как зачем.. Performance, Scalability, and High Availability..А родные средства от MS SQL не тянут или слишком дорого? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 01:54 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SERG1257skyANAНу как зачем.. Performance, Scalability, and High Availability..А родные средства от MS SQL не тянут или слишком дорого?Дорого и трудозатратнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 01:58 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANAА родные средства от MS SQL не тянут или слишком дорого?Дорого и трудозатратнее.[/quot] А какие нагрузки были? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 07:08 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANAmad_nazgulпропущено... Если не нужен ACID, то можно NoSQL. В противном случае только SQL.Хм. А мы поддержку ACID самостоятельно реализовали поверх MongoDB. Но основным хранилищем пока остаётся MS SQL Server В том то все и дело! Зачем что-то делать, когда уже все есть? Т.е. зачем нужно MongoDB для кэша, когда то же самое можно добиться настройками SQL-сервера? Я понимаю, что NoSQL нужны в некоторых случаях (их не так много, но они есть) Но пихать их всюду смысла нет, т.к. придется делать кучу "велосипедов", только для того чтобы реализовать то что есть давно в SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 07:47 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
mad_nazgulskyANAпропущено... Хм. А мы поддержку ACID самостоятельно реализовали поверх MongoDB. Но основным хранилищем пока остаётся MS SQL Server В том то все и дело! Зачем что-то делать, когда уже все есть? Т.е. зачем нужно MongoDB для кэша, когда то же самое можно добиться настройками SQL-сервера? Я понимаю, что NoSQL нужны в некоторых случаях (их не так много, но они есть) Но пихать их всюду смысла нет, т.к. придется делать кучу "велосипедов", только для того чтобы реализовать то что есть давно в SQL.Вы это к чему? Так, рассуждаете? Мы не используем MongoDB для кэша и не пихаем всюду. Да и не делаем кучу "велосипедов". :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 10:27 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
DPH3skyANAА родные средства от MS SQL не тянут или слишком дорого?Дорого и трудозатратнее. А какие нагрузки были?[/quot]Уточните свой вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 10:28 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
mad_nazgulЕсли не нужен ACID, то можно NoSQL. В противном случае только SQL. Почему же так, есть и такие NoSQL: http://www.fisglobal.com/products-technologyplatforms-gtm ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 16:39 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Собственно документо-ориентированные СУБД ещё не использовал и даже не касался их. Вопрос касательно join'ов какая альтернатива? К примеру у нас есть запись под ней комментарии, сами комментарии можно положить в массив, но каждый комментарий оставлен конкретным пользователем, со своим ником, аватаркой - которую он может хоть каждый день менять, как правильно организовать структуру и это всё вытащить? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 00:09 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SlaviskesСобственно документо-ориентированные СУБД ещё не использовал и даже не касался их. Вопрос касательно join'ов какая альтернатива? К примеру у нас есть запись под ней комментарии, сами комментарии можно положить в массив, но каждый комментарий оставлен конкретным пользователем, со своим ником, аватаркой - которую он может хоть каждый день менять, как правильно организовать структуру и это всё вытащить?Документо-ориентированная СУБД тут не нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 03:40 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANASlaviskesСобственно документо-ориентированные СУБД ещё не использовал и даже не касался их. Вопрос касательно join'ов какая альтернатива? К примеру у нас есть запись под ней комментарии, сами комментарии можно положить в массив, но каждый комментарий оставлен конкретным пользователем, со своим ником, аватаркой - которую он может хоть каждый день менять, как правильно организовать структуру и это всё вытащить?Документо-ориентированная СУБД тут не нужна. Где тут? Где бывает подобная ситуация и потребность в JOIN? Где бывают записи и комментарии к ним? Это же только абстрактный пример. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 12:28 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SlaviskesskyANAпропущено... Документо-ориентированная СУБД тут не нужна. Где тут? Где бывает подобная ситуация и потребность в JOIN? Где бывают записи и комментарии к ним?В блогах и форумах. SlaviskesЭто же только абстрактный пример.Плохой пример. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 14:01 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANASlaviskesпропущено... Где тут? Где бывает подобная ситуация и потребность в JOIN? Где бывают записи и комментарии к ним?В блогах и форумах. SlaviskesЭто же только абстрактный пример.Плохой пример. Ну собственно мой вопрос изначально и был "когда удобней использовать то или иное решение", на что получил ответ если не нужен ACID(а вами ещё добавлено, что и ACID сами реализовали) то можно использовать. Поэтому интересуюсь у людей кто на своей практике использовал в реальных проектах ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 14:47 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
SlaviskesskyANAпропущено... В блогах и форумах. пропущено... Плохой пример. Ну собственно мой вопрос изначально и был "когда удобней использовать то или иное решение", на что получил ответ если не нужен ACID(а вами ещё добавлено, что и ACID сами реализовали) то можно использовать. Поэтому интересуюсь у людей кто на своей практике использовал в реальных проектахВсё зависит от характера данных и их объёма. От предполагаемых операций с ними, количества этих операций в единицу времени и их профиля. От характера изменения перечисленных показателей в будещем. Когда ясно какие предполагаются данные, их объём, профиль нагрузки, тогда и видно какое решение подходит, а какое нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 15:02 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Slaviskes, задайтесь этими вопросами и попробуйте ответить себе самостоятельно: РСУБД решит ваши проблемы, или нужно искать NoSQL решение? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 15:03 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANASlaviskesпропущено... Ну собственно мой вопрос изначально и был "когда удобней использовать то или иное решение", на что получил ответ если не нужен ACID(а вами ещё добавлено, что и ACID сами реализовали) то можно использовать. Поэтому интересуюсь у людей кто на своей практике использовал в реальных проектахВсё зависит от характера данных и их объёма. От предполагаемых операций с ними, количества этих операций в единицу времени и их профиля. От характера изменения перечисленных показателей в будещем. Когда ясно какие предполагаются данные, их объём, профиль нагрузки, тогда и видно какое решение подходит, а какое нет. Нет, я прекрасно понимаю и осознаю, что каждый инструмент удобней в определённом конкретном случае и выбор нужно осуществлять в зависимости от конкретных параметров. Но это можно сказать о чём угодно, о выборе технологии\языка\платформы\библиотеки. Я не спрашиваю совета под конкретный свой проект, меня интересует опыт людей применявших на практике, ведь довольно не редки случаи когда выбранная технология при проектировании оказалась неудачной и в процессе реализации проекта это всё вышло боком или наоборот, смена\выбор технологии оказалась крайне удачной. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 15:16 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Slaviskes, окей. Ссылка на проект в моём профиле. В MongoDB хранятся данные CMS модуля системы. Почему MongoDB - писал выше. Где ещё используется MongoDB и как, можно узнать у MongoDB community (благо есть такое). Если есть более конкретные вопросы - задавайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 16:12 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANADPH3А какие нагрузки были?Уточните свой вопрос. Ну, вы решили вместо MS SQL (или другой РСУБД) использовать MongoDB с самодельной реализацией транзакций, при этом исходили из требований масштабирования и надежности. Интересно: на какую нагрузку (пишущих/читающих транзакций в секунду, время отклика) вы рассчитывали, какую надежность (в часах простоя в год, например или во времени восстановления) планировали, что в результате получилось, ну и как реализовывали HA для MongoDB между датацентрами :) И почему именно Mongo, а не та же Cassandra? Заранее спасибо ) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 15:34 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
DPH3skyANAпропущено... Уточните свой вопрос. Ну, вы решили вместо MS SQL (или другой РСУБД) использовать MongoDB с самодельной реализацией транзакций, при этом исходили из требований масштабирования и надежности.Не вместо. Мы решили кардинально переделать CMS модуль нашей системы. Только данные, относящиеся к этому модулю, перенесли в MongoDB. MS Sql Server остался основным хранилищем. DPH3Интересно: на какую нагрузку (пишущих/читающих транзакций в секунду, время отклика) вы рассчитывалиПиковая нагрузка у нас - 300+ запросов в секунду (если я правильно помню цифры). Рабочая - это десятки запросов в секунду. Из них большая часть - это читающие транзакции. Порядка 90%. DPH3какую надежность (в часах простоя в год, например или во времени восстановления) планировалиНе хуже чем только с MS Sql Server. Мы снимаем показатели за каждый месяц. Наши основные сервисы доступны 99.8-100% времени. 99.5% - это уже не очень хорошо :) Случаются конечно единичные простои, но не из-за СУБД. DPH3что в результате получилосьКак раз сейчас готовимся к gradual upgrade наших клиентов. Ещё только посмотрим, что получилось Но по нашим тестам с MongoDB в плане надёжности проблем нет. DPH3ну и как реализовывали HA для MongoDB между датацентрами :)Не понял о чём Вы. О каких датацентрах речь? DPH3И почему именно Mongo, а не та же Cassandra? Заранее спасибо )Мы рассмотрели разные варианты, взвесили за и против и решили, что MongoDB нам больше подходит. Основные данные CMS - это структура веб страниц и шаблонов страниц, а также история их изменений (версии). А это что? Правильно, документы :) Плюс возможность писать запросы к данным и наличие официального драйвера для C#. Вообще у на в корпоративной wiki (confluence) есть более полный перечень pros and cons, всего не помню. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 19:58 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
Slaviskes, об SQL vs NoSQL есть интересная статья ЗДЕСЬ Не скажу, что все ответы найдете, но, надеюсь, полезно будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2014, 13:07 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANAПиковая нагрузка у нас - 300+ запросов в секунду (если я правильно помню цифры). Рабочая - это десятки запросов в секунду. Из них большая часть - это читающие транзакции. Порядка 90%. Т.е. нагрузка не существенна, производительность не являлась сколь-нибудь существенным фактором? Как я понимаю специфику CMS, там довольно мало сложноструктурированных данных (документов, да), так что все равно все в кэшах. До этого как вы хранили эти данные в MS SQL? Блобы, текстовые поля, полная нормализация? В чем были проблемы с использованием решения на MS SQL? skyANAНе хуже чем только с MS Sql Server. Мы снимаем показатели за каждый месяц. Наши основные сервисы доступны 99.8-100% времени. Сколько отказов железа было за это время? На каком уровне? Сколько физических серверов использует MongoDB? skyANAНе понял о чём Вы. О каких датацентрах речь? Ну, вообще-то, когда я слышу о HA, то я сразу вспоминаю, что один датацентр - это в лучшем случае три девятки на долгих сроках, реально меньше. И если все-таки нужна высокая доступность, то это всегда разнесение системы по физически изолированным датацентрам. Если у вас нет требований защищаться от рисков уровня ДЦ - то ладно, хотя тогда зачем говорить о высокой доступности :) Но, впрочем, данные у вас в монго не слишком важные, потеряете - не страшно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2014, 18:35 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
DPH3skyANAПиковая нагрузка у нас - 300+ запросов в секунду (если я правильно помню цифры). Рабочая - это десятки запросов в секунду. Из них большая часть - это читающие транзакции. Порядка 90%. Т.е. нагрузка не существенна, производительность не являлась сколь-нибудь существенным фактором?Является. DPH3Как я понимаю специфику CMS, там довольно мало сложноструктурированных данных (документов, да), так что все равно все в кэшах.Почти всё в кэше, используем Couchbase, выше писал. History и Trash не кэшируются. DPH3До этого как вы хранили эти данные в MS SQL? Блобы, текстовые поля, полная нормализация? В чем были проблемы с использованием решения на MS SQL?Нормализация (структура и функционал был намного проще). Решение на MS SQL оказалось трудозатратнее и дороже по нашим оценкам. DPH3skyANAНе хуже чем только с MS Sql Server. Мы снимаем показатели за каждый месяц. Наши основные сервисы доступны 99.8-100% времени. Сколько отказов железа было за это время? На каком уровне? Сколько физических серверов использует MongoDB? skyANAНе понял о чём Вы. О каких датацентрах речь? Ну, вообще-то, когда я слышу о HA, то я сразу вспоминаю, что один датацентр - это в лучшем случае три девятки на долгих сроках, реально меньше. И если все-таки нужна высокая доступность, то это всегда разнесение системы по физически изолированным датацентрам. Если у вас нет требований защищаться от рисков уровня ДЦ - то ладно, хотя тогда зачем говорить о высокой доступности :) Но, впрочем, данные у вас в монго не слишком важные, потеряете - не страшно :)Это как посмотреть. Для нас важные :) За инфраструктуру у нас отвечают отдельные люди. Раньше было 12 физических серверов. Вроде как их заменили на 6 более мощных, старые вывели из эксплуатации. Также вся инфраструктура переводится на Hyper-V. Вроде как 4 гипервизора на тестовой. Сколько будет в продакшн, пока не скажу. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2014, 19:27 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANADPH3Т.е. нагрузка не существенна, производительность не являлась сколь-нибудь существенным фактором?Является. Тогда я, честно говоря, не понимаю. 300 запросов на чтение в секунду в пиках, без хитрых join, да еще и с внешним кэшированием - это вообще не нагрузка. skyANADPH3До этого как вы хранили эти данные в MS SQL? Блобы, текстовые поля, полная нормализация? В чем были проблемы с использованием решения на MS SQL?Нормализация (структура и функционал был намного проще). Решение на MS SQL оказалось трудозатратнее и дороже по нашим оценкам. Хм, если вас устроила модель Mongo, то уж банальные блобы в MS SQL уж всяко работали бы не хуже. Ни одной из "фишек" монго вы, похоже, не используете. skyANAЗа инфраструктуру у нас отвечают отдельные люди. Раньше было 12 физических серверов. Вроде как их заменили на 6 более мощных, старые вывели из эксплуатации. Также вся инфраструктура переводится на Hyper-V. Вроде как 4 гипервизора на тестовой. Сколько будет в продакшн, пока не скажу. Это только на монго или это всего на проект? И что сказали люди, отвечающие за инфраструктуру на выбор Монго? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2014, 00:13 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
DPH3skyANAпропущено... Является. Тогда я, честно говоря, не понимаю. 300 запросов на чтение в секунду в пиках, без хитрых join, да еще и с внешним кэшированием - это вообще не нагрузка.1. Если бы делали на MS SQL, то появились бы хитрые join; 2. Ну не ждать же нам, когда посещаемость наших сервисов не миллионами, а десятками миллинов в сутки будет измеряться? Мы же представляем динамику роста нагрузки и готовимся заранее. DPH3skyANAпропущено... Нормализация (структура и функционал был намного проще). Решение на MS SQL оказалось трудозатратнее и дороже по нашим оценкам. Хм, если вас устроила модель Mongo, то уж банальные блобы в MS SQL уж всяко работали бы не хуже.Опа на, вот тут я сильно засомневался в Вашей компетентности. Как бы Вы на блобах построили систему и обеспечили приемлимую скорость сериализации/десериализации, не говоря уже о шардинге, репликации и поддержке обновлений? DPH3Ни одной из "фишек" монго вы, похоже, не используете.О каких "фишках" речь? И с чего Вы решили, что мы их не используем? DPH3skyANAЗа инфраструктуру у нас отвечают отдельные люди. Раньше было 12 физических серверов. Вроде как их заменили на 6 более мощных, старые вывели из эксплуатации. Также вся инфраструктура переводится на Hyper-V. Вроде как 4 гипервизора на тестовой. Сколько будет в продакшн, пока не скажу. Это только на монго или это всего на проект? И что сказали люди, отвечающие за инфраструктуру на выбор Монго?На данный момент к MongoDB у них претензий нет. Со всеми критическими и важными проблемами разобрались. А вот к MS SQL... А на гипервизорах тестовой среды не только монго вертится, но и всё остальное под CentOS и Windows. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2014, 01:20 |
|
SQL or NoSQL
|
|||
---|---|---|---|
#18+
skyANA1. Если бы делали на MS SQL, то появились бы хитрые join; 2. Ну не ждать же нам, когда посещаемость наших сервисов не миллионами, а десятками миллинов в сутки будет измеряться? Э, вот тут я не понял. Если можно использовать document-oriented Mongo без join, то откуда появятся join в MS SQL? Да и кэширование у вас все-таки есть. Опа на, вот тут я сильно засомневался в Вашей компетентности. Как бы Вы на блобах построили систему и обеспечили приемлимую скорость сериализации/десериализации, не говоря уже о шардинге, репликации и поддержке обновлений? Э, ну, на такой нагрузке и при внешнем кэшировании шардинг даром не сдался. Репликация есть в том же MS SQL "из коробки" (а зачем, кстати, репликация, log shipping для надежности явно лучше схемы репликации в монго, а производительности одного инстанса вполне хватит). Ну а сериализация/десериализация в случае с монго никуда не девается (да и в C# вполне пристойно реализована). При чем тут "поддержка обновлений" - не совсем понял. Вообще, производительные системы на блобах именно на MS SQL уже давно не делал, а вот на Oracle и на DB2 делал и не раз - нет там никаких проблем. Ну, конечно, если делать сериализацию в XML на чистом reflection на мегабайтных документах - то да... Но зачем идиотизмом-то заниматься. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2014, 03:04 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552394]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
62ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 167ms |
0 / 0 |