- Xem file hướng dẫn Gephi trong đường dẫn trên hoặc phần 3.3.2 tiếp theo để biết cách load graph vào trong Gephi và chỉnh sửa để hiển thị đồ thị như ý.
4 PHẦN : GIẢI QUYẾT BÀI TOÁN SCALING CỦA CÁC MẠNG XÃ HỘI HIỆN NAY SỬ DỤNG NOSQL
SỬ DỤNG NOSQL
Như chúng ta đã biết, các ứng dụng chúng ta xây dựng sau khi chạy một thời gian với số lượng người dùng càng đông, truy xuất đồng thời lớn, các thao tác trên database CRUD ngày càng lớn thì ứng dụng chúng ta trở nên chậm chạp (lagging) và không đáp ứng performance theo yêu cầu.
Vấn đề đặt ra là làm sao mở rộng (scaling) ứng dụng cho phép hệ thống vẫn hoạt động trơn tru khi lượng người dùng truy xuất đồng thời lớn và lượng dữ liệu trao đổi cũng lớn. Đây chính vấn đề
Scalability mà tất cả các hệ thống lớn ngày nay đều phải giải quyết, ví dụ như các mạng xã hội hiện nay như Facebook, Twitter, Linkedin, Foursquare, Instagram…
Phần này sẽ đi khảo sát cách mà một số mạng xã hội hiện nay giải quyết vấn đề Scaling của họ như thế nào bằng cách sử dụng một số NoSQL databases và Distributed databases.
4.1 VẤN ĐỀ SCALING CHO MẠNG XÃ HỘI FOURSQUARE
Website : http://www.foursquare.com
Foursquarelà một trong những mạng xã hội mới nổi trong thời gian gần đây, nó cung cấp khả năng chia sẻ vị trí địa lý ( location-based ) bằng cách “check-in” các địa điểm mình tới và chia sẻ với bạn bè những điểm đến của mình, để nhận xét đánh giá những nơi yêu thích, hình thành nên một cộng đồng xã hội rất được giới trẻ yêu thích.
Foursquare là một trong những hệ thống tiên phong sử dụng CSDL Document MongoDB mà ta trình bày ở trên. Sau đây ta đi xem xét 1 số khía cạnh kỹ thuật sử dụng trong Scaling của Foursquare.
Bài toán đặt ra
Foursquare ban đầu sử dụng 1 db chung, nhưng khi càng nhiều người sử dụng, data ngày càng lớn, thì kiến trúc csdl quan hệ không thể giúp dễ dàng scaling ứng dụng.
Thống kê vào thời điểm đó, Foursquare có • > 9 tr người dùng
• ~ 3 tr checkins / ngày
• > 300k merchants • > 60 employees
Rõ ràng lượng dữ liệu trong 1 ngày là rất lớn
Lý do sử dụng MongoDB của Foursquare ?
Có vài lý do mà các kỹ sư tại Foursquare quyết định chọn MongoDB cho chiến lược scaling của mình
• Auto-Sharding (Tự động phân mảnh)
MongoDB hỗ trợ phân mảnh tự động dữ liệu cho phép Foursquare có thể scale quá trình ghi xuống các nodes (scale writes across many nodes ). Tự viết một lớp xử lý phân mảnh
(sharding layer) đòi hỏi nhiều công sức, do đó Foursquare đã sử dụng MongoDB cho việc này. • Geo-spatial Indexing ( Lập chỉ mục cho các dữ liệu địa lý không gian)
Ngoài việc phân mảnh tự động, Foursquare còn hưởng lợi từ tính năng hỗ trợ index cho dữ liệu địa lý, việc này rất phù hợp với business của Foursquare là về location-based data. • Replica Sets (Replicate dữ liệu)
Tính năng Replica Sets có trong MongoDB đem lại tính sẵn sàng cao (high availability) qua hệ thống các node dự phòng khi gặp lỗi. Do Foursquare chạy trên Amazon EC2 (Amazon Elastic Compute Cloud) nên các nodes có thể gặp lỗi vào bất kỳ lúc nào, khắc phục lỗi tự động (automatic failover) là 1 điểm lợi lớn dành cho Foursquare.
• Document-oriented model (mô hình dữ liệu tài liệu)
Mô hình dữ liệu lưu trữ của MongoDB với các đối tượng giống JSON cho phép ta sử dụng giống như những object quen thuộc của OOP, ngược hẳn với việc lưu trữ theo cấu trúc bảng của CSDLQH. Vì các developers suy nghĩ theo hướng đối tượng nên dễ dàng hơn khi sử dụng.
Và đây là thông số của hệ thống server sử dụng MongoDB tại Foursquare (tại thời điểm 24/5/2011)
- 8 clusters
some sharded, some not
some master/slave, some replica set
- ~ 40 machines (68.4GB, m2.4xl on EC2)