Так і дооптимізуємось... незабаром будемо сидіти всі безробітні і голодні. Залиште людям можливість нормально робити баги, фіксити їх і отримувати зарплату.
Чудова стаття, як і тема для неї.
Особисто маю справу на проекті із збреженням в базу (імпортом) великої кількості бізнес даних через доволі розгалужену доменну модель з використанням batching підходу (використовуємо Spring Batch).
Близька серцю проблематика. В моєму випадку — це пошук ідеального балансу між швидкістю збереження даних та довжини транзакції виходячи з варіацій набору бізнес даних, задля мінімізації ризику ролбеків та дедлоків.
Що дійсно стає в нагоді, так це те, що MySQL пропонує суттєвий набір метаданих, які зберігаються в information та performance схемах, чи операційної іформації через стейтменти на кшталт show engine, що в сукупності дає змогу всеохоплююче дослідити стан речей та історію подій в базі.
Моя особиста думка, що тема InnoDB Locking доволі непроста для освоєння,
але дико цікава коли досліджуєш її з глибини і починаєш розуміти як це працює, які проблеми вирішує. Транзакційна модель, блокування, рівні ізоляції, консистентність даних і все таке.
А взагалі, як на мене, це вибухова суміш задоволення для інженера працювати зі стеком Java/Spring/MySQL/AWS маючи при цуьому розширене розуміння часто непростих механізмів роботи цих технологій.
декілька коментарів щодо запропонованих рішень до тестових завдань Олександра С.
//2. Знайти унікальні предмети, які вивчають студенти зі списку students
List uniqueSubjects — одне лише поєднання цих слів вже викликає сумнів в навичках опитуваного
//4. Відсортувати студентів за предметами відповідно до наведеного списку
// Варіант рішення через лямбди
помилка в логіці яка приводить до протилежного очікуваному результату
.mapToInt(o -> subjects.size() - subjects.indexOf(o)).sum()
індекс елемента визначається з кінця списку, хоча потрібно з початку
.mapToInt(o -> subjects.indexOf(o)).sum()
p.s. варіант рішення через лямбди і мапу видадуть обернені результати якщо задати вхідні дані з різними сумарними значеннями приорітетів.
// Варіант рішення через мапу
це рішення вірне однак можна покращити- разом із Java Streams в Сomparator додали набір дуже зручних вспоміжних методів.
наприклад, сomparator::comparing дозволяє уникнути дублювання визначення критерію сортування:
List sortedStudents = students.stream()
.sorted((student1, student2) -> {
int priority1 = student1.subjects.stream().mapToInt(subjectPriority::get).sum();
int priority2 = student2.subjects.stream().mapToInt(subjectPriority::get).sum();
return Integer.compare(priority1, priority2);
})
.toList();
List sortedStudents = students.stream()
.sorted(Comparator.comparing(student -> student.subjects.stream().mapToInt(subjectPriority::get).sum()))
.toList();
До речі, на Донбасі видобувають й біле золото також — Артемсіль) Правда зараз вже солевидобуток довелось весь переносити на Закарпаття(