Pull to refresh
12
0
Михаил Бесчётнов @TerminusMKB

User

Send message
Я не вижу смысла спорить. Если вам не нужен шардинг — рад за вас :)
Если кому-то он нужен (наверное, очевидно, что у разных проектов разные потребности, и мы не сможем рассмотреть все случаи), то его наличие — это плюс.
Когда база перестанет влезать в дисковый массив — тогда очень нужен :)
С минусами я не спорю, но если БД реально большая — деваться особо некуда.
Я бы сказал, единственное действительно неоспоримое преимущество — шардинг из коробки. Преимущество в скорости (по крайней мере по сравнению с последними релизами PostgreSQL) под большим вопросом.
Я ебеем начал прошлой осенью пользоваться (мелочёвка из Китая до 200 руб и пара девайсов по несколько тысяч) и из примерно 20 посылок одна мелкая пропала с концами (вернули деньги), а остальные приходили в СПб в пределах месяца, отдельные — за две недели. После прочитанных многочисленных ужастиков считаю, что это достаточно неплохо.
Как я не боролся, настраивая каждую новую версию, чтобы было «как раньше», но это уже перебор.
В 29 решил настроить панель инструментов. Выбрал соответствующий пункт контекстного меню.
В результате — переместить на панели инструментов ничего не удалось и, что интересно, не удалось и выйти из режима настройки штатным способом (нажатием на «Завершить настройку»). Закрытие/открытие браузера не помогло. А помогло только включение любого расширения, требующего перезагрузки браузера, и вот после этой перезагрузки он, ура, вышел из режима настройки пенели инструментов.

«Доплнительная панель» (даже переведено с ошибкой) отключай/не отключай, при перезагрузке браузера появляется вновь каждый раз.
Спасибо, попробую привыкнуть к Chrome, хоть Яндекс.Бар в firefox мне нравится сильно больше, и табы, не умеющие скролится, бесят.
Вот интересно, будет ли когда-нибудь OneNote для iPad поддерживать запароленные разделы :(
Я безмерно рад за вас, тёзка. И сожалею, что еще не обладаю вашим опытом.
Да, обращал. Также видел (сейчас, правда, найти сходу не смог) тесты, показывающие, что некий заметный прирост скорости дампа был только при двух потоках, а при трёх и более — уже несерьезно. Правда там уже, вероятно, всё в винты упирается.
Скажу так — мы не упирались в тормоза функциональных индексов. И я как-то даже не вижу причин, почему они могут быть медленнее. Точных сравнительных тестов показать не могу — не делали.
Мне кажется, однозначно ответить на вопрос, что лучше — разбивать большие апдейты или нет, может ответить только тот, кто знает логику работы конкретного приложения. В моём представлении, транзакции призваны обеспечить целостность записанных данных. Т.е., грубо говоря, если в моём приложении все, скажем, 10'000 записей должны или обновиться, или НЕ обновляться (а промежуточные варианты меня, допустим, не устраивают), я бы пихнул всё в одну транзакцию, хоть оно, типа, и нежелательно. Другое дело, что ситуаций с таким выбором лучше не допускать при продумывании архитектуры )
А, ну это понятно. Я бы не стал называть это потерями :)
Особенно это начинает работать если fill_factor не 100% и все новые записи у вас «месятся» в начале файла.

Именно в начале файла или в свободной зоне, определяемой значением fill factor?
В нашем случае он может и не лочит, но обеспечивает такую нагрузку на БД, что состояние практически эквивалентно простою проекта, хоть какие-то операции может быть и проходят :)
правда в случае чего вы потеряете все данные начиная с момента начала дампа.

Поясните, пожалуйста, этот момент. Работает БД, начинаем делать бекап. Бекап обламывается (хех, место на диске закончилось, было). Получаем битые бекап (можно сделать снова) и целую нормальную базу. Или я что-то не понял, или потерь нет.
С fill factor может получиться интересно, но там результат вроде как сильно зависит от характера обновлений/удаления записей. Если обновлять записи большими пачками, то никакого fill factor'а не хватит ). Аналогично, если запись идёт в множество потоков, может потребоваться ставить значение и пониже, до 80 — 70. С другой стороны, размер БД гарантированно возрастает и стоит ли овчинка выделки — с каждой таблицей нужно смотреть, как обычно, отдельно. В общем, всё туда же — надо тесты погонять )
Интересно. Если будет время, попробую провести и опубликовать тесты по вашему рецепту и тому, что сам написал. С тестами то оно нагляднее будет.
12 ...
8

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity