The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск СУБД SQLite 3.34.0, opennews (ok), 03-Дек-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


39. "Выпуск СУБД SQLite 3.34.0"  –3 +/
Сообщение от Siborgium (ok), 03-Дек-20, 20:12 
Я тоже не понимаю, зачем нужны быстрые и масштабируемые базы, когда можно взять SQLite захлебываться на базе в 500 мегабайт.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

59. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (-), 04-Дек-20, 02:09 
Вообще скулайт может быть довольно быстрым и на базе 500 мегов захлебываться он может только у совсем уж дилетантов. Вот если б вы 50 гигабайт сказали, там может быть кто-то и поверил бы уже. А такие утырки даже к амароку и прочим кдешным адресбукам мускул прут.
Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Lex (??), 04-Дек-20, 07:17 
Действительно, зачем давать возможность каждому приложению обладать своей БД, компактной и неплохо масштабируемой( для большинства задач среднестатистического приложения ) - ведь в каждое приложение можно тянуть по постгресу/мускулу/оракловой_или_мелкомягкой_БД, а то и вообще - зачем приложениям свои БД - пусть хранят все в одной, общей на рабочую станцию, развернутой на чем-то мощном и масштабируемом.. и все кому ни лень чтоб могли лезть туда, что-то писать, что-то читать - авось не сломается.. ну а если сломается, то не беда - всего лишь потеряются данные вообще всех приложений рабочей станции, ведь их все фактически в одной куче хранили :)

Это к слову о том, что разные продукты годятся для решения разных задач.
Ну а в случае с "лайтом", так на нем не грех организовать и какую-нибудь БД средненького сайта чем утянуть постгрес или мускул.. особенно, на фоне роста популярности SSD и снижения их стоимости

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

85. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от _hide_ (ok), 04-Дек-20, 11:37 
Вы подняли очень интересный вопрос: когда можно остановиться и перестать тратить силы на разработку и оптимизацию (в данном случае, не программно/аппаратную оптимизацию, а оптимизацию здравого смысла) и оставить только затраты на управление/маркетинг продукта/решения.
В идеальном мире ситуация, когда база данных тормозит, должна означать проблему масштабирования, в реальном 99,99% -- ошибка архитектора при разработке конечного приложения и некачественный минимальный внутренний аудит решения по вопросам производительности.
Когда Вы говорите, что для среднего сайта сойдёт SQLLite и никаких проблем не возникнет, то Вы не учитываете фактор человеческой безграмотности при реализации. Когда 90% запросов это чтение данных, 10% запись протоколов и логов, то тут никаких проблем ни у кого не возникнет (да, придется настроить партиции для оптимизации чтений/записи во времени) до той поры, пока автор-герой просто не сделает таблицу наполняемую данными со скоростью 100RPS и без индексов, а потом весь сайт научит эти данные читать (на всякий случай). Пройдет месяц, год и... Да, пора переходить на MySQL|PG|ORACLE|MSSQL, потому что никто не знает как и почему так сделано, а поменять драйвер базы данных и поправить несколько запросов проще, чем перелопачивать все. Вопрос в том, что данные нужно было либо обслуживать и индексировать, либо сразу хранить в РСУБД. Автор-герой уже давно получил ещё 10-15 проектов в свое резюме, а новые жертвы пока не знают о своем будущем.
<sarcasm>И какие мы делаем из этого выводы? Правильно! SQLLite тормозит.</sarcasm>
Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 04-Дек-20, 12:19 
> пока автор-герой просто не сделает таблицу наполняемую данными со скоростью 100RPS и без индексов

между нами, девочками - если тебе правда 100RPS - тебе придется смириться с отсутствием обычных индексов (во всяком случае, отличных от primary key) И это одна из неплохих вариаций на тему использования sqlite, ага, у нее накладные расходы на запись минимальные, пожалуй - просто надо заранее думать, как потом читать это будешь и соломку там отдельную стелить - прокси-кэшем обычно, ага.

И нет, никакой чудо mssql тебя тут не спасет, он тоже, не поверишь, в конечном итоге в файл на диске пишет, а с диска в память читает, никаких таких чудес. А от меганавороченного оптимизатора запросов орацла тебе тут тож никакого щастья.

Надо либо искать что-то узкоспециализированное и не-sql,  параллелящееся шардингом, либо таки оптимизировать код, не надеясь что база за тебя будет думать (ой, хм, простите, замечтался).

Ответить | Правка | Наверх | Cообщить модератору

125. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от Аноним (-), 05-Дек-20, 04:57 
На 100rps с сколь-нибудь вменяемым key-value тебе никакой шардинг просто не потребуется. Особенно на SSD.
Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 10:38 
угу. оно просто крэшнется, как обычно. Знаем мы этих, "вменяемых".

Не говоря уже о том, что никто не обещал что там key-value (я вообще слабо представляю, что в эту конструкцию ложится толком), а не банальный лог какой.

Ответить | Правка | Наверх | Cообщить модератору

132. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от _hide_ (ok), 05-Дек-20, 13:18 
> между нами, девочками - если тебе правда 100RPS - тебе придется смириться
> с отсутствием обычных индексов (во всяком случае, отличных от primary key)

Ну не знаю, 10К RPS MySQL показывает себя вполне прилично. Индексов, кроме простых, конечно не создать, но проблем особых не будет. А SQLLite-у индексы конечно очень мешают.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

136. "Выпуск СУБД SQLite 3.34.0"  +/
Сообщение от пох. (?), 05-Дек-20, 14:21 
> Ну не знаю, 10К RPS MySQL показывает себя вполне прилично. Индексов, кроме
> простых, конечно не создать, но проблем особых не будет. А SQLLite-у

я полагаю - на таком паттерне и sqlite у тебя "особых проблем не будет"

> индексы конечно очень мешают.

не очень, но таки да, мешают. А если их налепить от балды - то будут мешать уже сильно (как, собственно, и в mysql) Отдельные граждане, у которых оно, помнится, под 40k разгонялось, вместо обычных индексов использовали fts с собственными патчами.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру