| 1.2, 4eburashk (?), 13:39, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Для небольших проектов или сайтов или приложений или ботов или утилит sqlite - самое то.
Много где использую и пока не подводило. Годнота.
| | |
| |
| 2.3, kai3341 (ok), 14:01, 23/04/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
 Она под нагрузкой начинает безбожно тормозить. То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить 'взрослые' БД. С чтением вроде бы всё ок
| | |
| |
| 3.4, Андрей (??), 14:14, 23/04/2019 [^] [^^] [^^^] [ответить]
| +15 +/– |
Оно как бы для мелких задач и заточено. Это типа как лопата в огороде.
А если у вас грядка с гектар, тут без трактора не обойтись...
| | |
| 3.5, MBG (?), 14:59, 23/04/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Тестировал базы размером до терабайт — не тормозит. В продакшене объём данных пишется порядка 100Гб в сутки и сотни или более запросов на чтение ежесекундно — все ок. Покажите свой тестовый сценарий, если есть что показать.
| | |
| |
| 4.25, Аноним (25), 22:30, 23/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
А что у вас за проект такой? Возможно у вас есть то, что может меня заинтересовать, а у меня есть то, что может заинтересовать вас.
| | |
| |
| 5.37, MBG (?), 20:23, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
У меня задачи это обработка и хранение геопространственных данных - например, реалтайм данные о автомобильном трафике. Когда-то тестировал SQLite на больших базах по тем временам (4+ГБ лет 15 назад), были баги, репортил, починили, с тех пор комфортно использую на намного больших базах. Аналогично с пространственным расширением Spatialite. Кое-что можно у меня в блоге посмотреть по тэгу
https://geomapx.blogspot.com/search/label/SQLite
Используя команду ATTACH и разделяя базы по минутным/часовым/суточным - нет проблем хранить и обрабатывать много терабайт данных. Для обработки данных за выбранный период нужно приаттачить нужный набор баз и собрать из них необходимые записи. Если интересно, можно нагуглить мою переписку с инженером Гугл и по совместительству создателем индекса для полнотекстового поиска в SQLite - будет понятно, как его для пространственных данных использовать и почему он хорош для больших баз (миллиарды записей), когда штатный индекс не годится (тесты есть в блоге, см. выше). PostgreSQL/PostGIS также использую, когда не нужна высокая производительность. В SQLite детерминированный планировщик и плюс он намного эффективнее на чтение, когда обрабатываемый набор данных на порядки превышает объем доступной оперативки.
| | |
|
|
| 3.6, Аномномномнимус (?), 15:00, 23/04/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
А "взрослые" это какие? Есть СУБД которая не начинает тормозить с ростом числа записей в секунду? Ну ка расскажи нам про альтернативную физику
| | |
| |
| 4.7, пох (?), 15:24, 23/04/2019 [^] [^^] [^^^] [ответить]
| –4 +/– | |
есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т д
потом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.
в sqlite огорчает разьве что категорическое нежелание автора использовать нефайловые локи - хотя бы в виде sysV ipc. Понятно, его основные потребители на это не пойдут, а два перпендикулярных api в одной программе не уживутся.
| | |
| |
| 5.8, Анонимус_б6_выпуск_3 (?), 15:41, 23/04/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
>есть такие, где крошки до поры можно заметать под ковер - с шардингом, кластеризацией и т д
>потом, правда, все равно лопнет, но можно к этому моменту уже сменить работу.
вот она, вся суть современного разработчика ПО любой направленности =((
| | |
| |
| 6.11, пох (?), 17:02, 23/04/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
чо эта только разработчика? Я тоже уволиться могу! Сейчас только бригадира уговорю паспорт мне отдать...
| | |
|
| |
| 6.10, пох (?), 17:01, 23/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
заметанием крошек под ковер, ага.
С тем же успехом я могу "решить" эту проблему, заменив диски на nvme.
А чо, решил же ж?
При этом он дополнительных проблем создает - мама не горюй.
(если мы про шардинг именно sql'ей)
| | |
| |
| |
| 8.15, пох (?), 18:08, 23/04/2019 [^] [^^] [^^^] [ответить] | –1 +/– | ну тебе шардинг какую проблему-то решает - недостаточность пропускной способност... текст свёрнут, показать | | |
| |
| |
| 10.33, Аноним (33), 13:13, 24/04/2019 [^] [^^] [^^^] [ответить] | –1 +/– | На чтение выборку не решает, потом процессинг это почему-то Oracle поверх IBM ... текст свёрнут, показать | | |
| |
| 11.35, пох (?), 16:53, 24/04/2019 [^] [^^] [^^^] [ответить] | +/– | про оракловые кластеры я тоже могу рассказать, с выражениями Только их модерато... текст свёрнут, показать | | |
|
|
|
|
|
|
| 5.12, Аномномномнимус (?), 17:04, 23/04/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это история про то что нагрузка размазывается более равномерно по серверам, но это никак не отменяет того факта, что при увеличении нагрузки увеличиваются и тормоза. Ну вот не деться от этого никуда, т.к. количество данных растёт. И при шардинге можно ещё упереться в скорость сети, раз уж на то пошло, а не только в скорость SSD локалхоста. Магию опять не завезли
| | |
| |
| 6.14, rshadow (ok), 17:22, 23/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между датацентрами. И т.д. Под капотом конечно будет куча технологий и боли =)
Планеты тоже каждая своим шардом будет. Т.к. физические ограничения на скорость света не дадут работать онлайн с _общей базой данных_ ;-)
| | |
| |
| 7.16, пох (?), 18:10, 23/04/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> По идее магия тут простая. Сначала делишь нагрузку между серверами. Не хватает - между
> датацентрами. И т.д.
и тут оно обычно лопается.
пришедший после твоего своевременного увольнения (или прикапывания в подвале, если не успел) - с матом переводит все на какую-нибудь кашмандру или еще каку хрень, специально разработанную для подобного применения, и переделывает все что работало с базой, чтобы исключить cross-dc доступ или хотя бы уменьшить его до минимума.
| | |
| |
| |
| 9.23, пох (?), 19:49, 23/04/2019 [^] [^^] [^^^] [ответить] | –2 +/– | а, да, я когда из такого увольнялся - еще ничем не воняло , я еще пол-года дума... текст свёрнут, показать | | |
|
|
|
|
|
| 4.21, Анончик (?), 18:44, 23/04/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Есть СУБД которая не начинает тормозить с ростом числа записей в секунду?
Конечно есть. Те СУБД котрые поддерживают table partitioning
| | |
| |
| 5.27, Аномномномнимус (?), 23:20, 23/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Серьёзно? Просто переводим на котрые поддерживают table partitioning и потом если лить на диск больше данных, он начнёт быстрее работать? Правда-правда? И ОЗУ больше станет? И проц быстрее? Правда-правда? Как здорово!
| | |
| |
| 6.34, Аноним (33), 13:14, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Думаю имелось ввиду количество тех данных что уже залиты и по которым есть индексы...
| | |
|
|
|
| 3.28, Аноним (28), 00:25, 24/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> То есть с ростом числа записей в секунду наступает переломный момент, когда следует переходить 'взрослые' БД. С чтением вроде бы всё ок
Вы не поверите, но с чтением тоже есть переломный момент, когда оно перестанет успевать :-)
| | |
|
|
| 1.24, Аноним (25), 22:24, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Напоминаю всем, что VACUUM реализован крайне ***ищно. Сначала копируется файл в журнал, потом журнал - в другой файл. Итого - для вакууминга базы размера X требуется 3*X места на диске и 2*X прокачек данных в оперативу и обратно. И это не считая перемещений головок.
Короче, не используйте вакуум, используйте официальный костыль https://github.com/sqlite/sqlite/blob/master/tool/fast_vacuum.c - это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.
| | |
| |
| 2.29, Аноним (28), 00:30, 24/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> это единственное, что смогло вакуумировать базу на 40 гигов, не выжрав всё место на винте.
Извините, но у меня на телефоне больше места.
| | |
| |
| 3.32, tonys (??), 12:56, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Действительно, зачем думать? Купите себе еще иопсов и террабайтов.
| | |
| |
| 4.36, пох (?), 16:55, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
ну говорят же ж вам - сколько не чеши думалку, все равно придется покупать, только еще и дороже выйдет.
чудес не бывает.
просто не храните в sql данные, которые не собираетесь обрабатывать.
| | |
|
|
| 2.30, пох (?), 07:12, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
он реализован без необходимости останавливать систему на время вакуума и при этом crash proof. Поэтому лог и double write (как и при любой другой работе с базой). У "fast" версии этого не предусмотрено.
но вообще-то это вы что-то очень странное делаете, что вам в принципе остро необходим vacuum. Тут чай не постгрез.
короче, не используйте vacuum на реально работающих базах, используйте pragma optimize и только по показаниям.
для 40G базенки скорее всего не нужно регулярно делать ни того, ни другого.
| | |
|
|
