Bài viết nằm trong series Multithread từ hardware tới software với Java. Câu hỏi 1: từ các bài trước, khi chia các bài toán ra thành nhiều phần có thể xử lý đồng thời và implement với multi-thread sẽ nhanh hơn single-thread. Vậy nhanh hơn bao nhiêu lần, làm thế nào để tính được con số cụ thể hoặc gần đúng nhất? Câu hỏi 2: lập trình multi-thread có thật sự nhanh hơn single-thread không? Câu hỏi 3: số lượng thread nên bao nhiêu là đủ? Bài viết này sẽ giải đáp 2 mối bận tâm trên. Let's begin!

Các câu truy vấn SQL chạy rất nhanh với Database local, nhưng lên môi trường production thì chậm hơn rùa bò. Vì sao vậy? Có một vài yếu tố liên quan đến môi trường như CPU chậm, RAM ít, bandwidth giới hạn, vô vàn các lý do từ bên thứ 3 mà anh em dev có thể nghĩ đến. Tuy nhiên có một thứ giả vờ quên là design lởm, query tồi :joy:. Và chính mình đã gặp trường hợp như vậy. Chạy local 0,1(s) nhưng lên production là 5(s)... Series lần này sẽ giới thiệu về cách phân tích, optimize và một vài tính chất của PostgreSQL để tăng performance. 001: Có những cách nào để tối ưu SQL Query? (published) 002: Hiểu về Index để tăng performance với PosgreSQL P1 (published) 003: Hiểu về Index để tăng performance với PosgreSQL P2 (published) 004: Hiểu về Index để tăng performance với PosgreSQL P3 (published)

Bài viết nằm trong series Performance optimization với PostgreSQL. Phần trước đã tìm hiểu về một mớ lý thuyết của Vacuum, phần này sẽ xem qua về reindex và tập trung vào practice với vacuum để kiểm nghiệm thực tế thế nào. Let's begin. 1) Reindex REINDEX, nghe phát hiểu luôn ý nghĩa, đó là thực hiện build lại index cho index/table/database... REINDEX INDEX index_name; REINDEX TABLE table_name;

Bài viết nằm trong series Performance optimization với PostgreSQL. PostgreSQL multi-version cuncurrency control giúp giải quyết concurrent read/write nhưng sẽ nảy sinh vấn đề khác: Bloating: UPDATE/INSERT/DELETE nhiều dẫn tới dư thừa số lượng lớn các dead tuple (old record version). Chúng không còn giá trị nhưng vẫn nằm đấy, làm tăng disk space. Wraparound transaction id: số lượng transaction id vượt quá 2^32 có thể dẫn tới sai lệch data. Bài viết này sẽ tìm hiểu PostgreSQL xử lý chúng thế nào. Let's begin. 1) Vacuum

Bài viết nằm trong series Performance optimization với PostgreSQL. Bài trước chúng ta đã biết về các phương pháp giúp tăng performance của SQL query. Bài hôm nay sẽ giới thiệu về một trong các phương pháp đó, indexing thần thánh. Từ bài này sẽ liên quan nhiều đến practice nên các bạn chuẩn bị env và data trước. Mình sử dụng Docker cho nhanh. Start PostgreSQL và pgAdmin4: docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres

Bài viết nằm trong series Performance optimization với PostgreSQL. Việc concurrent read/write data tưởng chừng đơn giản nhưng với programming thì không ez tí nào. Chém thế chứ cũng không quá phức tạp khi sử dụng các cơ chế sync/lock, tuy nhiên nó làm giảm performance. Vậy có cách nào không cần lock mà vẫn concurrent read/write không? Let's begin. 1) Multi-version concurrency control Với phần trước, ta biết rằng database sử dụng shared lock và explicit lock trong concurrent read/write để đảm bảo data integrity. Nhược điểm của nó là việc read/write không thể diễn ra cùng lúc vì có thể dẫn đến half-written.

Bài viết nằm trong series Performance optimization với PostgreSQL. Phía client, hay nói cách khác là application, chúng ta tương tác với database thông qua các câu lệnh DML (INSERT/UPDATE/DELETE)... và bản chất tất cả đều được thực thi như một transaction nếu không explicit khai báo và không auto commit. Nếu execute single query: UPDATE TABLE X SET COLUMN = 'Y' WHERE ID = 1; Nó được thực thi giống như:

Bài viết nằm trong series Performance optimization với PostgreSQL. 1) Overview SQL là ngôn ngữ truy vấn dữ liệu dạng bảng được phát triển vào những năm 1970s. Mặc dù hơn 50 tuổi đời nhưng vẫn được sử dụng phổ biến. Câu hỏi đặt ra, có bí ẩn gì mà nó phổ biến và tồn tại lâu đến vậy? Ngắn gọn thôi, vì nó phù hợp, rất phù hợp, cực kì phù hợp để truy vấn dữ liệu dạng bảng với Relational Database. Vài năm trước rộ lên phong trào NoSQL cho các Non-relational Database. Tuy nhiên đẳng cấp vẫn là mãi mãi, sau vài năm phát triển các kĩ sư nhận ra không thể bỏ SQL và Relational Database và nó đang trỗi dậy mạnh mẽ. Khá giống Monolithic Architecture vs Microservice Architecture. Gần như tất cả các thể loại data từ đơn giản đến phức tạp đều có khả năng cấu trúc được dưới dữ liệu dạng bảng. Ngoài ra, một lý do nữa nó phổ biến là các query viết dưới dạng khai báo, chúng ta chỉ ra những gì mình muốn và không quan tâm đến việc nó được thực thi như thế nào. SELECT * FROM ENGINEER e WHERE e.title = 'Software Engineer';

Bài viết nằm trong series Microservice Architecture: Từ lý thuyết đến thực tiễn. 1) Monolithic Architecture Thời còn sinh viên, chúng ta đã quen thuộc với việc phát triển sản phẩm với mô hình Monolithic, hiểu đơn giản toàn bộ code được đóng gói và phát triển trên duy nhất một project/source code. Số lượng thành viên dao động từ 1 - 5 người. Khi giảng có yêu cầu mới, team sẽ thảo luận chia task và thực hiện implement, build and run và thấy không có gì magic ở đây cả, mọi thứ vẫn perfect. Từ đó, có một vài kết luận khi triển khai Monolithic Architecture với ưu điểm như sau: Quá trình phát triển sản phẩm đơn giản, thay đổi code, build và deploy trên duy nhất một project. Không mất nhiều công để set up môi trường. Phát triển trên ngôn ngữ duy nhất nên chỉ cần nắm sâu và chắc ngôn ngữ đó là giải quyết được hầu hết các vấn đề.

Chúng ta đã nghe nhiều về Microservice, từ sự kì diệu cho đến những lợi ích mà nó đem lại khi so sánh với kiến trúc Monolithic. Tuy nhiên cũng có khó khăn và bất tiện nhất định triển khai và đặc biệt là làm cách nào, làm như thế nào để giải quyết. Với lý do đó, mình sẽ viết một series về Mircoservice Architecture với các chủ đề: 001: Monolithic và sự hình thành của Microservice (published) 002: Bài toán và cách triển khai Microservice P1 003: Bài toán và cách triển khai Microservice P2 004: Các vấn đề cần xử lý trong mô hình Microservice

Bài viết nằm trong series Performance optimization với PostgreSQL. Với series Multi-thread programming từ hardware đến software, ta biết rằng read/write data với multi-thread có thể dẫn đến data race, vấn đề nhỏ nhưng hậu quả lớn, khiến chương trình sai lệch trầm trọng. Nghe hơi huy hiểm, nhưng cách giải quyết không có gì phức tạp, sử dụng các cơ chế mutual exclusion là giải quyết được vấn đề này. Optimistic concurrency control và Pessimistic concurrency control là hai khái niệm trong database nói đến cách xử lý write data với multi-session/multi-transaction. Cùng tìm hiểu kĩ hơn trong bài viết này nhé. Let's begin. 1) Pessimistic lock Pessimistic concurrency control hay pessimistic lock đều diễn tả về cơ chế giải quyết xung đột khi có nhiều transaction cùng thay đổi dữ liệu trên một hoặc một tập các records.

Bài viết nằm trong series Multithread từ hardware tới software với Java. Parallel computing hardware P2 có đề cập đến khái niệm data race. Mục đích của bài viết này sẽ giải thích rõ hơn về data race và các cách xử lý với Java. Let's begin. 1) Data race là gì? Với multi-thread programming, cần chú ý khi tương tác với các biến vì vấn đề cache coherency (đọc bài trước nếu chưa rõ nhé). Data race xảy ra khi có từ 2 thread/process trở lên cùng truy cập vào một vùng nhớ chung (shared resource) với ít nhất 1 thread/process thực hiện việc thay đổi giá trị trên vùng nhớ đó. Nguyên nhân xảy ra data race trong một process do cache coherency. Ví dụ cụ thể:

Bài viết nằm trong series Java memory management & performance. Với bài viết đầu tiên, cùng nhìn sơ lược về cách JVM thực thi các đoạn code của chúng ta như thế nào nhé. 1) WORA Java nổi tiếng với WORA, nghĩa là Write once, run anywhere, viết một lần và chạy mọi nơi. Oh shit, wtf... làm sao lại có một ngôn ngữ thần thánh như vậy, bí ẩn phía sau nó là gì? Lấy một ví dụ trong thực tế, nếu mình chỉ biết tiếng Việt, liệu mình có thể đi du lịch nước ngoài được không? Làm sao mình giao tiếp được với người bản địa. Chẳng có nhẽ với mỗi một quốc gia khác nhau mình phải học ngôn ngữ của họ. Có 3 cách cơ bản để giải quyết vấn đề trên:

Bài viết nằm trong series Multithread từ hardware tới software với Java. Nói đến multi-thread programming chắc không thể bỏ qua Thread pool. Các Java developer chắc đã quen thuộc với ExecutorService bao gồm nhiều loại thread pool và khá mạnh mẽ. Tuy nhiên, nó đã phải thứ tốt nhất giúp cho chương trình được parallel execution chưa? Cùng đi tìm câu trả lời với lượt bài cuối trong series này nhé. Trước hết cần hiểu về cooperative và preemptive trong multi-tasking. Let's begin. 1) Multi-tasking Multi-tasking là gì? Việc các đầu bếp liên tục đổi chỗ cho nhau ở bài trước để thực hiện phần việc của mình một cách concurrent chính là ví dụ của multi-tasking.

Bài viết nằm trong series Java memory management & performance. JIT Compiler biến những hot spots bytecode thành native code và lưu trữ ở JVM Code cache để những lần thông dịch sau có thể dùng luôn native code giúp tăng performance cho chương trình. Bài viết hôm nay sẽ tìm hiểu kĩ hơn về JVM Code cache, tuning JVM Code cache size và AoT Compiler. Let's begin. 1) JVM Code cache JVM Code cache là nơi lưu trữ các native code sau khi được compile từ bytecode. Và chỉ những hot spot code mới được compile sang native code chứ không phải toàn bộ. Xem model bên dưới để có cái nhìn tổng quan về quá trình JVM thực thi các dòng code nhé. Nếu quan sát kĩ, bạn có nghĩ ra cách nào để optimize flow trên không?

Bạn là Fresher, Junior, Mid-level hay Senior? Nếu có ý tưởng mới về một ứng dụng nào đó, chúng ta có nên nhảy vào.. code luôn hay không? Nếu bạn biết design trước để tránh đi lầm đường lạc lối, sau đó đến coding thì bạn đã bước một chân từ Fresher/Junior sang Mid-level/Senior rồi. Tất nhiên cần một vài yếu tố khác nhưng design đúng, design chuẩn đã được hơn phân nửa tấm thẻ thông hành. Với series này, cùng đi qua về khái niệm của Object-Oriented Programming (lập trình hướng đối tượng). Sau đó là các bước tiến hành, các công cụ để tạo nên một bản thiết kế tuyệt vời cho ứng dụng mình mong muốn. Let's begin. 001: Procedural programming và Object-Oriented programming (published) 002: Object và Class trong Object-Oriented Programming (published) 003: Các tính chất cơ bản trong OOP P1 (published) 004: Các tính chất cơ bản trong OOP P2 (published)

Bài viết nằm trong series Object-Oriented from real life to software. Với phần trước, chúng ta đã tìm hiểu về Abstraction và Encapsulation. Bài viết hôm nay sẽ giới thiệu 2 tính chất còn lại của OOP là: Inheritance. Polymorphism. 1) Inheritance Kế thừa là thừa hưởng, gìn giữ và tiếp tục phát huy các giá trị tinh thần hoặc những di sản văn hóa của dân tộc - Theo từ điển tiếng Việt.

Bài viết nằm trong series Object-Oriented from real life to software. OOP có 4 tính chất cơ bản cần nhớ trong suốt cuộc đời lập trình viên, đó là một cái bánh - A PIE, viết tắt của: Abstraction. Polymorphism. Inheritance. Encapsulation. Ngôn ngữ kĩ thuật khô khan, nên việc tiếp thu 4 tính chất này đối với mình khi còn học trên ghế nhà trường là.. rất khó khăn. Mỗi ngôn ngữ lập trình sẽ có syntax khác nhau. Mà concept của OOP là đem hiện thực đời sống thường ngày vào trong lập trình, do đó mình không lấy ví dụ coding mà chủ yếu tập trung vào ví dụ thực tế với mục tiêu hiểu sâu nắm rõ. Let's begin.

Bài viết nằm trong series Java memory management & performance. Thông dịch (interpret) và biên dịch (compile), hai khái niệm này cần phân biệt rõ. Với bài trước ta biết Java là interpreter language, ngôn ngữ thông dịch. Tuy nhiên với JVM và cụ thể là JIT Compiler, sẽ có một phần của chương trình trở thành compiled language, khiến cho tốc độ của Java application phần nào được cải thiện. Một ví dụ dễ hiểu như sau, ta có một văn bản bằng tiếng Anh, và muốn nó được dịch sang ngôn ngữ tiếng Nhật để được thực thi. Có 2 cách: Compile: dịch sẵn thành tiếng Nhật ra một văn bản khác, sau đó đưa văn bản đã dịch cho ông người Nhật thực thi. Interpret: thuê phiên dịch viên, đọc từng dòng tiếng Anh và dịch sang tiếng Nhật cho ông người Nhật thực thi. Cùng tìm hiểu về JVM Compiler với C1 compiler và C2 compiler trong bài viết này nhé. Let's begin.

Bài viết nằm trong series Performance optimization với PostgreSQL. Tiếp tục bài trước, cùng đi tìm hiểu về 2 loại partition còn lại là: Partition by list Partition by hash Let's begin. 1) Partition by list