Aside

1. Tổng quan về Hive

Apache Hive là 1 kho dữ liệu (data warehouse) hỗ trợ người sử dụng có thể dễ dàng hơn trong việc quản lý và truy vấn đối với các tập dữ liệu lớn được lưu trữ trên các hệ thống lưu trữ phân tán (distributed storage). Hive được xây dựng dựa trên cơ sở của Apache Hadoop, nó cung cấp các tính năng chinh sau:

  • Công cụ cho phép dễ dàng thực hiện tác vụ như trích xuất, vận chuyển và lưu trữ dữ liệu.
  • Cơ chế để xử lý cho nhiều định dạng dữ liệu khác nhau.
  • Truy cập tới dữ liệu dạng files được lưu trữ trực tiếp ở trong Apache HDFS hoặc đối với nhiều hệ thống lưu trữ dữ liệu khác như Apache HBase.
  • Thực hiện query thông qua MapReduce.

Hive định nghĩa ra một ngôn ngữ truy vấn đơn giản có cú pháp gần giống với SQL  (SQL-like query language) được gọi là HiveQL, nó cho phép người sử dụng đã quen thuộc với các truy vấn SQL thực hiện việc truy vấn dữ liệu. Ngoài ra ngôn ngữ này còn cho phép các lập trình viên người đã quen thuộc với MapReduce framework có thể nhúng các mappers và reducers cho chính họ viết ra để thực thi nhiều hơn nữa các phân tích phức tập mà không được hỗ trợ bởi các hàm đã có sẵn trong ngôn ngữ HiveQL. HiveQL cung có thể được mở rộng với các custom scalar functions (UDF’s), aggregations (UDAF’s) và các table funtions (UDTF’s)

Hive không yêu cầu dữ liệu phải được đọc và ghi dưới một định dạng của riêng Hive (Hive format). Hive hoạt động tốt trên Thrift và các định dạng dữ liệu riêng của người sử dụng.

Hive không được thiết kế để cho các giao dịch online (OLTP workloads) và không nên dùng cho các real-time queries và các cập nhật trên từng dòng trong 1 table (row-level). Hive hoạt động tốt nhất cho các batch jobs trên các tập dữ liệu lớn, mà ở đó dữ liệu được thêm vào liên tục (append-only data) ví dụ như web logs.  Hive có khả năng mở rộng theo chiều ngang tốt (thực thi tốt trên 1 hadoop cluster có số tượng máy biến đổi), có khả năng tích hợp với MapReduce framework và UDF, UDAF, UDTF; có khả năng chống chịu lỗi và mềm dẻo đối với các dữ liệu đầu vào của chính nó.

Các thành phần cấu hình Hive bao gồm HCatalog và WebHCat. HCatalog là một thành phần của Hive. Đây là lớp quản lý lưu trữ  cho Hadoop (table and management layer), nó cho phép người dùng với các công cụ xử lý dữ liệu khác nhau bao gồm cả Pig và MapReduce thực thi hoạt động đọc, ghi một cách dễ dàng hơn. WebHCat cung cấp một dịch vụ cho phép bạn có thể thực thi Hadoop MapReduce (hoặc YARN), Pig, Hive.

 

 2.Kiến trúc của Hive

Hive có các thành phần chính là :

  • Hive UI: cung cấp giao diện cho phép người sử dụng tương tác với hệ thống Hive. Hive cung cấp nhiều phương thức khác nhau cho phép người sử dụng tương tác với Hive:
    • CLI: giao diện dạng shell cho phép người sử dụng tương tác trực tiếp qua command line.
    • Hive Web Interface: giao diện Web cho phép người sử dụng thực hiện các truy vấn thông qua giao diện Web.
    • Hive Thrift Server: cho phép các client từ nhiều ngôn ngữ lập trình khác nhau có thể thực hiện tương tác với Hive.
  • Hive Driver: thành phần nhận các truy vấn và chuyển các truy vấn này thành các MapReduce Jobs để tiến hành xử lý yêu cầu của người sử dụng.
    • Driver: nhận các truy vấn, thành phần này thực hiện việc quản lý các sessions và cung cấp các API để thực thi và lấy dữ liệu trên  JDBC/ODBC interfaces.
    • Compiler: thành phần hiện việc phân tích ngữ nghĩa đối với các query, lấy các thông tin metadata cần thiết về table và partion từ metastore để sinh ra các excution plan.
    • Execute engine: thành phần thực thi các execution plan được tạo bởi compiler (submit các job tới MapReduce). Ngoài ra thành phần execution enginen này thực hiện việc quản lý các dependencies của các bước trong mỗi execution plan, thực thi từng bước này.
  • Hive Metastore: thành phần lưu trữ các metadata của Hive: table, partion, buckets bao gồm cả thông tin về các column trong mỗi table, các serializers và desrializers cần thiết để thực hiện việc đọc và ghi dữ liệu. Metastore sử dụng một cơ sở dữ liệu quan hệ để lưu trữ dữ liệu của chính mình.

  1

Hình 2.1. Kiến trúc của Hive

 3. Hoạt động của Hive

 

2

Hình 3.1. Mô hình hoạt động của Hive

 

Quy trình hoạt động của Hive có thể được mô tả theo các bước sau:

  1. Các truy vấn tới từ User Interface (CLI, Hive Web Interface, Thirft Server) được gửi tới thành phần Driver (Bước 1 hình 3.1)
  2. Driver tạo ra mới 1 session cho truy vấn này và gửi query tới compiler để nhận lấy Execution Plan (Bước 2 hình 3.1)
  3. Compilter nhận các metadata cần thiết từ Metastore (Bước 3, 4 hình 3.1). Các metadata này sẽ được sử dụng để kiểm tra các biểu thức bên trong query mà Compiler nhận được.
  4. Plan được sinh ra bởi Compiler  (thông tin về các job (map-reduce) cần thiết để thực thi query sẽ được gửi lại tới thành phần thực thi  (Bước 5hình 3.1)
  5. Execution engine nhận yêu cầu thực thi và lấy các metadata cần thiết và yêu cầu mapreduce thực thi công việc (Bước 6.1, 6.2, 6.3 hình 3.1)
  6. Khi output được sinh ra, nó sẽ được ghi dưới dạng 1 temporary file, temorary file này sẽ cung cấp các thông tin cần thiết cho các stages khác của plan. Nội dung của các temporary file này đưc execution đọc trực tiếp từ HDFS như là 1 phần của các lời gọi từ Driver (bước 7, 8, 9 hình 3.1)

 

4. Mô hình dữ liệu trong Hive

3

Hình 4.1. Hive Data Model

 

Dữ liệu trong Hive được tổ chức thành các kiểu sau:

  • Databases: là namespace cho các tables, dùng để nhóm và quản lý các nhóm tables khác nhau.
  • Tables: tương tự như table trong các hệ cơ sở dữ liệu quan hệ. Trong Hive table có thể thực hiện các phép toán filter, join và union… Mặc định thì dữ liệu của Hive sẽ được lưu bên trong thư mục warehouse trên HDFS. Tuy nhiên Hive cũng cung cấp kiểu external table cho phép ta tạo ra và quản lý các table mà dữ liệu của nó đã tồn tại từ trước khi ta tạo ra table này hoặc nó được lưu trữ ở  1 thư mục khác bên trong hệ thống HDFS. Tổ chức row và column bên trong Hive có nhiều điểm tương đồng với tổ chức Row và Column trong các hệ cơ sở dữ liệu quan hệ. Hive có 2 kiểu table đó là: Managed Table và External tables.
  • Partions: Mỗi table có thể có 1 hoặc nhiều các khóa mà từ đó xác định dữ liệu sẽ được lưu trữ ở đâu. Ví dụ table web_log có thể phân chia dữ liệu của mình theo từng ngày là lưu dữ liệu của mỗi ngày trong 1 thư mục khác nhau bên dưới đường dẫn  warehouse. Ví dụ: /warehouse/web_log/date=”01-01-2014″
  • Buckets: Dữ liệu trong mỗi partion có thể được phân chia thành nhiều buckets khác nhau dựa trên 1 hash của 1 colume bên trong table. Mỗi bucket  lưu trữ dữ liệu của nó bên dưới 1 thư mục riêng. Việc phân chia các partion thành các bucket giúp việc thực thi các query dễ dàng hơn.

 

4.1. Managed Tables and External Tables

Managed Tables:

Khi bạn tạo mới 1 tables thì Hive  sẽ chuyển các dữ liệu này tới tới kho dữ liệu của nó (warehouse directory). Tuy nhiên bạn vẫn có thể tạo ra các external table, với khai báo thì nàythì Hive biết rằng dữ liệu dữ liệu này đã tồn tại ở trên 1 location khác bên ngoài warehouse directory.

Sự khác biệt của chúng sẽ xảy ra ở 2 quá trình LOAD và DROP. Ta bắt đầu với việc tìm hiểu managed table trước tiên:

Khi bạn thực hiện việc load dữ liệu vào bên trong managed table, nó sẽ thực hiện việc chuyển dữ liệu tới bên trong warehouse directory. Ví dụ:

 

CREATE TABLE managed_table(dummy STRING);
LOAD DATA INPATH '/user/hadoop/data.txt' INTO table managed_table;

 

Với khai báo này thì Hive sẽ thực hiện việc di chuyển file hdfs://user/tom/data.txt tới  Hive’s warehouse cho managed_table được lưu trữ tại đường dẫn:hdfs://user/hive/warehouse/managed_table.

Nếu table bị xóa đi với câu lệnh :

DROP TABLE managed_table; 

thì table bao gồm cả metadata và dữ liệu chứa bên trong table đó sẽ bị xóa đi, trong trường hợp này câu lện DROP sẽ thực hiện việc xóa dữ liệu và dữ liệu bên trong table trên sẽ không còn tồn tại nữa.

External tables:

External tables lại có cách đối xử khác biệt. Bạn sẽ quản lý việc tạo mới và xóa đi đối với dữ liệu. Địa chỉ của external data sẽ được khai báo khi tạo mới bảng:

CREATE EXTERNAL TABLE external_table (dummy STRING)
LOCATION '/user/hadoop/external_table';
LOAD DATA INPATH '/user/hadoop/data.txt' INTO TABLE external_table;

Với từ khóa EXTERNAL, Hive hiểu rằng nó không trực tiếp quản lý các dữ liệu này bởi vậy nó sẽ không thực hiện việc di chuyển chúng tới Hive’s data warehouse. Trên thực tế là Hive không thực hiện việc kiểm tra xem dữ liệu trên External localtion có tồn tại hay không. Đây là 1 tiện ích khác hữu dụng, nó cho phép ta có thể thực hiện việc khởi tạo dữ liệu khi  tạo 1 table trên  Hive. Và khi dữ liệu việc drop 1 external table thì Hive chỉ thực hiện việc xóa đi các metadata của nó.

4.2. Partions and Buckets

Hive tổ chứng dữ liệu của nó thành các partions, là 1 cách để phân chia dữ liệu thành các khối khác nhau dựa trên giá trị của  partion columns ví dụ như date. Sử dụng partions có thể khiến cho quá trình query trở nên nhan hơn/

Table hoặc partions cũng có thể tiếp tục phân chia thành các buckes, để giúp dữ liệu được tổ chức để sử dụng cho nhiều efficient query. Ví dụ, bucketing bởi userID có nghĩa là chúng ta cho thể thực hiện việc tính toán nhanh hơn trên mỗi query của người sử dụng thay vì thực hiện nó trên 1 tập dữ liệu được sắp xếp 1 cách ngẫu nhiên.

 

Partions:

Một table trong Hive có thể được partioned theo nhiều chiều khác nhau. Ví dụ như logs file có thể được partions bởi ngày nó được tạo ra và country  để cho phép thực hiện các query theo location 1 cách dễ dàng hơn.

CREATE TABLE logs (ts BIGINT, line STRING)
PARTITIONED BY (dt STRING, country STRING);
 

Khi ta chuyển dữ liệu tới một partion talbe, thông tin về partion phải được xác định:

LOAD DATA LOCAL INPATH 'input/hive/partions/file1'
INTO TABLE logs
PARTITION (dt='2001-01-01', country='GB');

Đối với mức filesystem thì các partion đơn giản là được lưu trữ lồng bên trong nhau trong thư mục lưu trữ dữ liệu cả table đó.

/user/hive/warehouse/logs/dt=2010-01-01/country=GB/file1
                                                  /file2
                                       /country=US/file3
                         /dt=2010-01-02/country=GB/file4
                                       /country=US/file5
                                                  /file6

 

Table logs có 2 partions được chia theo trường date, 2010-01-01 và 2010-01-02, chúng được lưu trữ tương ứng trong các đường dẫn có tên dt=2010-01-01 và dt=2010-01-02 và 2 subpartions GB và US được lưu trữ bên trong các date partions, chúng có tên: country=GB và country=US:

Chúng ta có thể kiểm tra các partions trong Hive bằng câu lệnh:

hive> SHOW PARTITIONS logs;
dt=2001-01-01/country=GB
dt=2001-01-01/country=US
dt=2001-01-02/country=GB
dt=2001-01-02/country=US

Buckets

Có 2 lý do tại sao bạn nên tổ chức dữ liệu bên trong table (partions) thành các buckets. Điều đầu tiên là nó cho phép thực hiện các query 1 cách hiệu quả hơn. Bucketing tác động tới extra structure trên table. nó giúp Hive thực hiện các query 1 cách thuận lợi hơn. Ví dụ việc join giữa 2 table đã được bucked trên cùng 1 column –  đã thực hiện việc join columns – có thể hiệu quả tương tự như map-side join.

Partion vs bucket:

  • Partion thực hiện phân chia dữ liệu trong 1 table theo value của column key, mỗi partion key sẽ có 1 không gian lưu trữ của riêng nó.
  • Bucketing: thực hiện việc phân phối các key tới từng bucket khác nhau và mỗi partion lại chỉ có 1 key duy nhất.

 

4.3. Các kiểu dữ liệu trong Hive

Kiểu dữ liệu nguyên thủy:

Mỗi columns có 1 kiểu dữ liệu cố định. Các kiểu dữ liệu nguyên thủy sau sẽ được hỗ trợ đối với Hive:

  • Integers:
    • TINYINT – 1 byte integer
    • SMALLINT – 2 byte integer
    • INT – 4 byte integer
    • BIGINT – 8 byte integer
  • Boolean type
    • BOOLEAN – TRUE/FALSE
  • Floating point numbers
    • FLOAT – single precision
    • DOUBLE – Double precision
  • String type
    • STRING – sequence of characters in a specified character set

Các kiểu dữ liệu khác:

  • Structs: là kiểu dữ liệu mà mỗi phần tử bên trong đó có thể được truy cập thông qua việc sử dụng ký hiệu (.) . Ví dụ, với kiểu dữ liệu STRUCT {a INT; b INT} ví dụ trường a của nó có thể truy cập thông qua c.a
  • Maps (key-value tuples): là kiểu dữ liệu mà các phần tử sẽ được truy cập thông qua ký hiệu [‘element name’]. Đối với map M thực hiện việc map dữ liệu đối với khóa ‘group’ -> thì dữ liệu sẽ được sử dụng bởi trường M[‘group’]
  • Arrays (indexable lists): Kiểu mảng.

5.Metastore

The metastore là trung tâm lưu trữ của metadata của Hive. Metastore được thi thành 2 thành phần: a services và backing store dùng để lưu trữ dữ liệu. Mặc định thì metastore service chạy trong cùng 1 jvm với Hive services và bao gồm luôn cả 1 Derby database instances được lưu trữ trên local disk. Mô hình này được gọi là embedded metastore configuration.

Sử dụng embedded metastore  là cách đơn giản nhất để bắt đầu với Hive, mặc dù 1 embedded Derby database chỉ cho phép truy cập vào files ở trên disk 1 lần ở cùng 1 thời điểm, điều đó có nghĩa là bạn chỉ có thể có 1 session duy nhất có thể sử dụng dữ liệu trong metastore. Nếu ta thử khởi động session số 2 thì sẽ gặp được thông báo lỗi

 4

Hình 5.1. Hive Metastore

 

Giải pháp để hỗ trợ sử dụng nhiều session cùng 1 lúc là sử dụng standalone database. Cấu hình này còn được gọi tên là local mestastore, với nó thì metastore services vẫn tiếp tục chạy trong cùng 1 JVM với Hive services nhưng nó thực hiện kế t nối tới database thông qua 1 process khác, database này có thể nằm trên local machine hoặc trên remote machine. Bất kỳ JDBC-compliant database có thể được sử dụng bằng việc thiết lập thuộc tính javax.jdo.option.*.

MySQL là lựa chọn phổ biến cho việc lưu trữ standalone metastore. Trong trường hợp này javax.jdo.option.ConnectionURL sẽ được thiết lập là:jdbc:mysql://dbname?createDatabaseIfNotExist=true và javax.jdo.option.ConnectionDriverName được thiết lập thành com.mysql.jdbc.Driver.  JDBC driver jar file cho MySQL phải được xuất hiện trong Hive’c classpath.

Còn một kiểu mô hình nữa là remote-metastore, trong đó 1 hay nhiều metastore server được chạy trên các process riêng biệt. Nó mang tới  khả năng tốt hơn trong việc quản lý và đảm bảo tính an ninh.

 

5

 

Hình 5.2. Các cấu hình cho metastore

6. Một ví dụ về sử dụng Hive

Sau các phần trên, ta đã có cái nhìn khá tổng quát về Hive. Phần này sẽ thực hiện việc phân tích dữ liệu trong HDFS với Hive. Kịch bản sử dụng được đưa ra là ta sẽ sử dụng Hive để phân tích dữ liệu thu được từ các apache webserver được lưu trữ trên HDFS. Các file log này sẽ được thu thập từ các webserver bên trong hệ thống, và từ đó ta có thể thực hiện việc thống kê quá trình sử dụng trong hệ thống. Nội dung của 1 file Log sẽ có định dạng như sau:

64.242.88.10 - - [07/Mar/2004:16:05:49 -0800] "GET /twiki/bin/edit/Main/Double_bounce_sender?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12846
64.242.88.10 - - [07/Mar/2004:16:06:51 -0800] "GET /twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523
64.242.88.10 - - [07/Mar/2004:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291
64.242.88.10 - - [07/Mar/2004:16:11:58 -0800] "GET /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 200 7352
64.242.88.10 - - [07/Mar/2004:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253
64.242.88.10 - - [07/Mar/2004:16:23:12 -0800] "GET /twiki/bin/oops/TWiki/AppendixFileSystem?template=oopsmore¶m1=1.12¶m2=1.12 HTTP/1.1" 200 11382
64.242.88.10 - - [07/Mar/2004:16:24:16 -0800] "GET /twiki/bin/view/Main/PeterThoeny HTTP/1.1" 200 4924
64.242.88.10 - - [07/Mar/2004:16:29:16 -0800] "GET /twiki/bin/edit/Main/Header_checks?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12851
64.242.88.10 - - [07/Mar/2004:16:30:29 -0800] "GET /twiki/bin/attach/Main/OfficeLocations HTTP/1.1" 401 12851
64.242.88.10 - - [07/Mar/2004:16:31:48 -0800] "GET /twiki/bin/view/TWiki/WebTopicEditTemplate HTTP/1.1" 200 3732
64.242.88.10 - - [07/Mar/2004:16:32:50 -0800] "GET /twiki/bin/view/Main/WebChanges HTTP/1.1" 200 40520
64.242.88.10 - - [07/Mar/2004:16:33:53 -0800] "GET /twiki/bin/edit/Main/Smtpd_etrn_restrictions?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12851
64.242.88.10 - - [07/Mar/2004:16:35:19 -0800] "GET /mailman/listinfo/business HTTP/1.1" 200 6379
64.242.88.10 - - [07/Mar/2004:16:36:22 -0800] "GET /twiki/bin/rdiff/Main/WebIndex?rev1=1.2&rev2=1.1 HTTP/1.1" 200 46373
64.242.88.10 - - [07/Mar/2004:16:37:27 -0800] "GET /twiki/bin/view/TWiki/DontNotify HTTP/1.1" 200 4140
64.242.88.10 - - [07/Mar/2004:16:39:24 -0800] "GET /twiki/bin/view/Main/TokyoOffice HTTP/1.1" 200 3853
64.242.88.10 - - [07/Mar/2004:16:43:54 -0800] "GET /twiki/bin/view/Main/MikeMannix HTTP/1.1" 200 3686
64.242.88.10 - - [07/Mar/2004:16:45:56 -0800] "GET /twiki/bin/attach/Main/PostfixCommands HTTP/1.1" 401 12846

Ta thực hiện lưu trữ file  này dưới đường dẫn /user/logs/access.log.

Ta thực hiện việc tạo 1 Hive table để map với các dữ liệu này.

CREATE EXTERNAL TABLE request(address STRING, info STRING) ROW FORMAT
              DELIMITED FIELDS TERMINATED BY '- -'
              LINES TERMINATED BY 'n'
              STORED AS TEXTFILE
              LOCATION '/user/logs/access.log';

Trong đó:

  • Dữ liệu trong access.log sẽ được map tới table “request”
  • Table request gồm có 2 column là adress và info tất cả đều có kiểu là STRING.
  • Các column được phân tách bằng nhóm ký hiệu “- -“, mỗi 1 line được đánh dấu kết thúc bằng ký hiệu “n”
  • Nơi chứa dữ liệu mà table request map tới là ”
    /user/logs/access.log"

     

Nếu không có exception nào được đưa ra thì ta có thể bắt đầu thực hiện việc truy vấn dữ liệu bên trong Hive table. Một số truy vấn mẫu:

Liệt kê tất cả thông tin thu được từ trong các table:

SELECT * FROM request;

Liệt kê các IP đã thực hiện truy cập tới:

SELECT DISTINCT address FROM request;

 

Liệt kê số lượng request theo từng IP:

SELECT address, count(1) FROM request
GROUP BY address ORDER BY address DESC;

 

Tài liệu tham khảo

1. Hadoop: The Definitive Guilde 2.0, Tom White, 2011

2. https://cwiki.apache.org/confluence/display/Hive/Home

 

Advertisements

Tổng quan MongoDb

1. NoSQL

1.1. Khái niệm

NoSQL là một khái niệm chỉ về một lớp các hệ cơ sở dữ liệu không sử dụng mô hình quan hệ. (RDBMS). RDBMS vốn tồn tại khá nhiều nhược điểm như có hiệu năng không tốt nếu kết nối dữ liệu nhiều bảng lại hay khi dữ liệu trong một bảng là rất lớn.

1 Hình 1 – Carlo Strozzi

NoSQL ra đời năm 1998 bởi Carlo Strozzi khi ông lập mới một hệ cơ sở dữ liệu quan hệ mã nguồn mở nhanh và nhẹ không liên quan đến SQL Vào năm 2009, Eric Evans, nhân viên của Rackspace giới thiệu lại thuật ngữ NoSQL khi Johan Oskarsson của Last.fm muốn tổ chức một hội thảo về cơ sở dữ liệu nguồn mở phân tán. Thuật ngữ NoSQL đánh dấu bước phát triển của thế hệ CSDL mới: phân tán (distributed) + không ràng buộc (non-relational).

1.2. Đặc điểm

  • NoSQL lưu trữ dữ liệu của mình theo dạng cặp giá trị “key – value”. Sử dụng số lượng lớn các node để lưu trữ thông tin – Mô hình phân tán dưới sự kiểm soát phần mềm
  • Chấp nhận dữ liệu bị trùng lặp do một số node sẽ lưu cùng thông tin giống nhau
  • Một truy vấn sẽ được gửi tới nhiều máy cùng lúc, do đó khi một máy nào đó không phục vụ được sẽ không ảnh hưởng lắm đến chất lượng trả về kết quả
  • Phi quan hệ – không có ràng buộc nào cho việc nhất quán dữ liệu
  • Tính nhất quán không theo thời gian thực: Sau mỗi thay đổi CSDL, không cần tác động ngay đến tất cả các CSDL liên quan mà được lan truyền theo thời gian.

1.3. Các dạng NoSQL cơ bản

Key – value data stores: Dữ liệu lưu dưới dạng cặp key – value. Giá trị được truy xuất thông qua key.

  • Ví dụ : Redis, Dynomite, Project Voldemort.
  • Thường cho: Content caching Applications
  • Ưu điểm: Tìm kiếm rất nhanh
  • Nhược điểm: Lưu dữ liệu không theo khuôn dạng (schema) nhất định

Column-based – Tabular: Cơ sở dữ liệu tổ chức dưới dạng các bảng. Gần giống với mô hình RDBMS. Tuy nhiên, Chúng lưu dữ liệu bởi các cột chứ không phải bằng các dòng. Nó khá thích hợp với để hiển thị bằng các phần mềm quản lý kho dữ liệu

  • Ví dụ : Apache Hbase, Apache Cassandra, Hypertable
  • Thường cho: các hệ phân tán file
  • Ưu điểm: Tìm kiếm nhanh, Phân tán dữ liệu tốt
  • Nhược điểm: Hỗ trợ được với rất ít phần mềm

Document-based: Dữ liệu (bán cấu trúc hay semi-structured) được lưu trữ và tổ chức dưới dạng một tập hợp các document. Các document này linh hoạt, mỗi document có một tập nhiều trường.

  • Ví dụ : Apache CouchDB và MongoDB
  • Thường cho: Web applications
  • Ưu điểm: Dùng khi dữ liệu nguồn không được mô tả đầy đủ
  • Nhược điểm: Hiệu năng truy vấn, Không có cú pháp chuẩn cho câu truy vấn dữ liệu

Graph-based data-stores: Những CSDL này áp dụng lý thuyết đồ thị trong khoa học máy tính để lưu trữ và truy xuất dữ liệu. Chúng tập trung vào tính rời rạc giữa các phần dữ liệu. Các phần tử đơn vị dữ liệu được biểu thị như một nút và liên kết với các thành phần khác bằng các cạnh.

  • Ví dụ : Neo4j, InfiniteGraph, DEX
  • Thường cho: Social networking, Hệ trợ giúp
  • Ưu điểm: Ứng dụng các thuật toán trên đồ thị như Đường đi ngắn nhất, liên thông,…
  • Nhược điểm: Phải duyệt nội bộ đồ thị, để trả lời lại các truy vấn. Không dễ để phân tán

2. MongoDB

2.1. Khái quát

MongoDB (bắt nguồn từ “humongous”) là một hệ cơ sở dữ liệu NoSQL mã nguồn mở. logo

Hình 2 – Logo của MongoDB

Thay cho việc lưu trữ dữ liệu vào các bảng có quan hệ với nhau như truyền thống, MongoDB lưu các dữ liệu cấu trúc dưới dạng giống với JSON(JavaScript Object Notation) và gọi tên là BSON. Dự án được bắt đầu triển khai vào tháng 10 năm 2007 bởi 10gen trong khi công ty này đang xây dựng một nền tảng như là dịch vụ (Platform as a Service) giống như Google App Engine. Phải đến năm 2009, dự án này được tách độc lập. Hệ thống có thể chạy trên Windows, Linux, OS X và Solaris. Nó được một số tổ chức sử dụng trong thực tế như:

  • Caigslist : Công ty làm việc trong lịch vực môi giới quảng cáo trên các website khác (giống adMicro của Việt Nam). MongoDB giúp cho công ty này quản lý hàng tỉ các bản ghi quảng cáo thuận tiện và nhanh chóng.
  • Foursquare là một mạng xã hội gắn các thông tin địa lý. Công ty này cần lưu dữ liệu của rất rất nhiều vị trí của các địa điểm như quán cafe, nhà hàng, điểm giải trí, lịch sử, … và ghi lại những nơi mà người sử dụng đã đi qua.
  • CERN : Trung tâm nghiên cứu năng lượng nguyên tử của Châu Âu, sử dụng MongoDB để lưu trữ lại các kết quả, dữ liệu thí nghiệm của mình. Đây là một lượng dữ liệu khổng lồ sẽ dùng để sử dụng trong tương lai.
  • MTV Networks, Disney Interactive Media Group, bit.ly, The New York Times, The Guardian, SourceForge, Barclays, …

2.2. Tại sao lại chọn MongoDB?

MongoDB có những ưu điểm sau đây

  • Dễ học, có một số nét khá giống với CSDL quan hệ – Quản lý bằng command line hoặc bằng GUI như RockMongo hoặc phpMoAdmin
  • Linh động, không cần phải định nghĩa cấu trúc dữ liệu trước khi tiến hành lưu trữ nó -> rất tốt khi ta cần làm việc với các dạng dữ liệu không có cấu trúc.
  • Khả năng mở rộng tốt (distributed horizontally), khả năng cân bằng tải cao, tích hợp các công nghệ quản lý dữ liệu vẫn tốt khi kích thước và thông lượng trao đổi dữ liệu tăng.
  • Miễn phí

2.3. Kiến trúc tổng quát

Một MongoDB Server sẽ chứa nhiều database. Mỗi database lại chứa một hoặc nhiều colection. Đây là một tập các documnents, về mặt logic thì chúng gần tương tự như các table trong CSDL quan hệ. Tuy nhiên, điểm hay ở đây là ta không cần phải định nghĩa trước cấu trúc của dữ liệu trước khi thao tác thêm, sửa dữ liệu… Một document là một đơn vị dữ liệu – một bản ghi (không lớn hơn 16MB). Mỗi chúng lại chứa một tập các trước hoặc các cặp key – value. Key là một chuỗi ký tự, dùng để truy xuất giá trị dạng : string, integer, double, … Dưới đây là một ví dụ về MongoDB document

{
_id : ObjectId("4db31fa0ba3aba54146d851a"),
username : "joegunchy",
email : "joe@mysite.org",
age : 26,
is_admin : true,
created : "Sun Apr 24 2011 01:52:58 GMT+0700 (BDST)"
}

Cấu trúc có vẻ khá giống JSON, tuy nhiên, khi lưu trữ document này ra database, MongoDB sẽ serialize dữ liệu thành một dạng mã hóa nhị phân đặc biệt – BSON. Ưu điểm của BSON là hiệu quả hơn các dạng format trung gian như XML hay JSON cả hệ tiêu thụ bộ nhớ lẫn hiệu năng xử lý. BSON hỗ trợ toàn bộ dạng dữ liệu mà JSON hỗ trợ (string, integer, double, Boolean, array, object, null) và thêm một số dạng dữ liệu đặc biệt như regular expression, object ID, date, binary, code. dbms

Hình 3 – So sánh giữa RDBMS và MongoDB

com

Hình 4 – So sánh Table với Collection

2.4. Cơ chế hoạt động chi tiết của MongoDB

2.4.1. Sharding

2.1.1.1. Sharding là gì?

Sharding là cơ chế tự động của MongoDB dùng để chia tách một dữ liệu kích thước lớn cho rất nhiều server (thường gọi là cluster). Sharding được thiết kế để phục vụ 3 mục điêu cơ bản sau

  • Làm cho cluster “trong suốt” với người dùng: Để hoàn thành nhiệm vụ này, MongoDB sử dụng một quá trình routing đặc biết gọi là mongos. Mongos đứng trước cluster, đóng vai trò điều phối việc truy cập đến shard nào, trả dữ liệu từ shard nào ra. Nó chuyển tiếp các request tới các server khác có tài nguyên hoặc đến cluster đằng sau nó. Sau đó lắp ráp lại, và gửi các response lại về cho các client. Do đó, các client không cần biết rằng chúng đang giao tiếp với cluster nào thật sự mà chỉ biết rằng mình đang kết nối tới một server bình thường. Đây gọi là tính “trong suốt” với người sử dụng

mongos

Hình 5 – Mongos

  • Làm cho cluster luôn sẵn sàng để đọc hoặc ghi: Một cluster còn tồn tại phải đảm bảo được rằng nó luôn sẵn sàng. Mỗi phần con trong cluster sẽ có ít nhất một vài tiến trình phục vụ dự bị trên máy khác.
  • Làm cho cluster phát triển “tự nhiên”: Bất cứ khi nào người dùng cần thêm dung lượng, họ có thể thêm một cách dễ dàng Mỗi cluster khi được quản lý lại “thể hiện” như một node riêng lẻ và dễ dàng config.

2.1.1.2. Cơ chế của Sharding

2.1.1.2.1. Cơ chế chia tách dữ liệu

Một shard là một hoặc nhiều server trong một cluster chịu trách nhiệm với một tập các dữ liệu lưu trữ. Ví dụ, nếu ta có một cluster chứa 1.000.000 documents – 1.000.000 tài khoản website, thì một shard chứa khoảng 200.000 tài khoản. Nếu shard có chứa nhiều hơn một server, thì mỗi server đó sẽ lưu một bản copy giống hệt nhau của một tập con dữ liệu. Điều này có nghĩa là một shard cũng là một bộ các bản sao dữ liệu rep

Hình 6 – Các bản sao dữ liệu trong một shard

Để đồng đều phân phối dữ liệu vào các shard, MongoDB lại di chuyển một tập con dữ liệu từ shard này sang shard khác. Việc chọn lựa tập con nào để chuyển đi lại phụ thuộc vào khóa mà ta chọn. Ví dụ, chúng ta sẽ chọn cách thức chia một collection của các user dựa vào trường username và sử dụng khoảng chia giống trong Toán học ‘[‘ , ‘]’ , ‘(‘ , ‘)’.

2.1.1.2.2. Cơ chế phân tán dữ liệu
2.1.1.2.2.1. Một khoảng cho một shard

Đây là cách đơn giản nhất để phân tán dữ liệu ra cho các shard. Mỗi shard sẽ đảm nhận một tập con dữ liệu. Giả sử có 4 shard và 4 khoảng chia dữ liệu, ta sẽ chia như sau: shard

Hình 7 – 4 khoảng cho 4 shard [a,f), [f,n), [n,t), [t,{)

Chia như thế này là rất dễ hiểu nhưng nó trở nên rất phức tạp cho các hệ thống lớn. Giả sử rằng có một lượng lớn đăng ký username có chữ cái bắt đầu thuộc [a,f), điều này làm cho shard 1 trở nên lớn, giải quyết đơn giản bằng cách điều chỉnh cho shard 1 chỉ lấy từ [a,c) và shard 2 lấy nhiều hơn, từ [c,n) shard2

Hình 8 – Giới hạn lại khoảng cho shard 1 sang shard 2

Mọi thứ có vẻ ok, nhưng nếu shard 2 trở nên overload thì lại giải quyết thế nào? Giả sử rằng shard 1 và shard 2 chứa 500GB dữ liệu, shard 3 và shard 4 mỗi cái chứa 300GB dữ liệu. Giải quyết vấn đề này như sau: shard3

Hình 9 – Chuyển dữ liệu sang shard tiếp theo

  • Chuyển 100GB từ shard 1 sang shard 2
  • Chuyển 200GB từ shard 2 sang shard 3
  • Chuyển 100GB từ shard 3 sáng shard 4

Mỗi shard đều chứa 400GB dữ liệu, có vẻ ổn. Tổng cộng, đã chuyển 400GB dữ liệu qua mạng, quá lớn!!! Cách khác, thêm mới một shard thì sao? Giả sử có 4 shard, mỗi shard hiện đang có 500GB dữ liệu, thêm vào shard 5 và chia dữ liệu. shard4

Hình 10 – Thêm mới shard rồi chia đều dữ liệu

  • Chuyển 400GB từ shard 4 sang shard 5
  • Chuyển 300GB từ shard 3 sang shard 4
  • Chuyển 200GB từ shard 2 sang shard 3
  • Chuyển 100GB từ shard 1 sang shard 2

Mỗi shard đều chứa 400GB dữ liệu, vẫn ổn. Tổng cộng, đã chuyển 1TB dữ liệu qua mạng, quá lớn!!! Rõ ràng là cách thức chia mỗi khoảng trên một shard này làm cho vấn đề trao đổi dữ liệu, xử lý trong hệ thống lớn trở nên quá đắt đỏ và tốn kém. Do đó, MongoDB không phân tán dữ liệu theo cách thô thiển như thế này, thay vào đó là nhiều khoảng trên nhiều shard.

2.1.1.2.2.2. Nhiều khoảng trên nhiều shard

Giả sử tình huống cần giải quyết giống với hình 8, shard 1 và shard 2, mỗi shard có 500GB dữ liệu còn shard 3 và shard 4 mỗi shard có 300GB dữ liệu. Lúc này, ta sẽ cho phép mỗi shard chứa nhiều phần của khoảng chia. Chia dữ liệu trong shard 1 thành hai khoảng :

  • 400GB cho [a,d)
  • 100GB cho [d,f)

Chia dữ liệu trong shard 2 thành hai khoảng :

  • 400GB cho [f,j)
  • 100GB cho [j,n)

Lúc này, ta di chuyển:

  • 100GB [d,f) từ shard 1 sang shard 4
  • 100GB [j,n) từ shard 2 sang shard 3

Vậy, kết luận cả 4 shard đều chứa 400GB dữ liệu và chỉ phải trao đổi qua mạng 200GB dữ liệu. Điều này chấp nhận được S

Hình 11 – Cho phép đa, không liên tiếp các khoảng cho phép ta lấy ra và di chuyển dữ liệu đi bất cứ đâu

Với ví dụ của hình 9, nếu ta thêm vào một shard mới, ta chỉ lấy đi 100GB dữ liệu trên mỗi 4 shard cũ để cho vào shard 5 mới, lúc này các shard đã lưu dữ liệu như nhau và thông lượng trao đổi dữ liệu qua mạng ở mức tốt nhất 400GB S11

Hình 12 – Hớt 100GB của mỗi shard ném vào shard 5

Đây là cách mà MongoDB phân tán dữ liệu giữa các shard với nhau, nếu có shard nào mất cân bằng, dữ liệu sẽ được điều chỉnh để phục hồi lại trạng thái cân bằng mới giữa các shard.

2.1.1.2.3. Cơ chế tách, tạo đoạn của Sharding

Khi ta quyết định phân tán dữ liệu, ta phải chọn ra một khóa được sử dụng để tách các khoảng với nhau (ở trên ta chọn username). Khóa này được gọi là shard key có thể là bất kỳ hoặc tập bất kỳ trường nào. Giả sử rằng collection của chúng ta có các document như sau (không kể ra_ids): DOCUMENTS Nếu ta chọn Age là shard key và khoảng là [15,26) -> Kết quả là d

2.1.1.2.3. Cơ chế Sharding các Collection

Lần đầu tiên khi shard một Collection – bảng, MongoDB chỉ tảo ra một chunk cho bảng này sẵn sàng cho việc thêm mới dữ liệu. Chunk này sẽ có khoảng là (-∞,∞), với giá trị -∞ tương đương bởi $minKey và ∞ tương đương với $maxKey. Dĩ nhiên nếu dữ liệu trong bảng là đủ lớn, MongoDB sẽ tự động chia thành nhiều chunk hơn để lưu dữ liệu. Khi dữ liệu lớn dần, MongoDB tự động tách chunk như sau: chia đôi khoảng hiện tại ra theo khoảng của dữ liệu chọn làm key. Ví dụ trên, giả sử nó chọn chia đôi thành

  • Một chunk chứa tuổi nhỏ hơn 15 (-∞,15)
  • Một chunk chứa tuổi lớn hơn hoặc bằng 15 [15, ∞)

Nếu tiếp tục có nhiều dữ liệu được thêm vào chunk [15, ∞), nó sẽ bị chia tiếp, chẳng hạn [15, 26) và [26, ∞). Hiện tại ta có 3 chunk: (-∞,15), [15, 26) và [26, ∞) và cứ như vậy. Yêu cầu đặt ra:

  • Việc chia chunk phải liên tiếp
  • Một chunk chỉ tương đương với một khoảng và ngược lại
  • Mỗi một document chỉ thuộc một và chỉ một chunk

chunk

Hình 13 – Chia một chunk ra thành hai

Một số chú ý

  • Việc chia chunk này phụ thuộc tất cả vào shard key do vậy MongoDB không cho phép ta thêm dữ liệu mà rỗng hoặc không có shard key (ít nhất phải để null). Ta cũng không thể đổi được giá trị trường shard key, muốn vậy, bắt buộc phải thay đổi từ phía client, sau đó xóa, và thêm lại document muốn đổi shard key.
  • Nếu ta thêm nhiều kiểu dữ liệu vào nội dung trường age ở trên, ví dụ như một mảng, boolean, số, string, null, … MongoDB vẫn chấp nhận và dùng quy tắc chia chunk cho sharding theo thứ tự sau:

null < numbers < strings < objects < arrays < binary data < ObjectIds < booleans < dates < regular expressions

  • Ở các hệ thống thực tế một chunk thường chỉ được 200MB dữ liệu (còn mặc định là 64 MB) Một chunk là đơn vị logic. Các document trong một chunk cũng không nhất thiết phải nối tiếp nhau trong đĩa cứng vật lý. Chúng vẫn rải rác ngẫu nhiên trong collection. Tuy chỉ có một document thuộc về chunk thứ i,  nếu và chỉ nếu shard key của nó thuộc khoảng chia của chunk thứ i.

2.4.2. Balancing – Cân bằng tải

Nếu có nhiều shard đang sẵn sàng và có thêm chứa thêm dữ liệu, MongoDB sẽ tiến hành chuyển dữ liệu từ các shard khác sang để cân bằng tải. Cách thức tiến hành là di chuyển các chunk từ shard này sang shard khác một cách tự động. Balancing cũng có thể bị tắt hoặc bật nếu admin muốn Balancing cũng không được đảm bảo ngay tức thì, chúng ta hãy xem ví dụ dưới đây s2

Hình 14 – Nếu cần bằng real time, sẽ có những tài nguyên bị di chuyển lãng phí

2.4.3. Cấu hình cho một Cluster

2.4.3.1. Chọn Shard Key

2.4.3.1.1 Low-Cardinality Shard Key

Đây là việc chọn khóa một cách trực quan như ví dụ “Tôi đang có 4 Shard, Tôi chọn một trường nào đó làm Shard key để sao cho chia được ok trường đó thành 4 khoảng”. Cụ thể hơn, ta có 7 khoảng chia vào 7 shard như sau:

  • (-∞, “Antarctica”)
  • [“Antarctica”, “Asia”)
  • [“Asia”, “Australia”)
  • [“Australia”, “Europe”)
  • [“Europe”, “North America”)
  • [“North America”, “South America”)
  • [“South America”, ∞)

continent

Hình 15 – Một Shard cho một Châu lục

Điều này mới đầu rất ổn. Nhưng để ý, nếu về lâu dài, dữ liệu trong châu Á chẳng hạn tự nhiên lên cao hơn các châu khác thì ta không biết sẽ phân chia lại khoảng các shard như thế nào để cân bằng vì đã chọn một shard – một châu lục rồi. Cách giải quyết tình thế là ở đây lấy thêm một trường nữa làm Shard Key. Shard key có hai trường sẽ cho phép chia thành nhiều khoảng hơn. Nhưng kết lại, đây nói chung không phải là cách chọn Shard Key tốt.

2.4.3.1.2. Ascending Shard Key

Như chúng ta đã biết, đọc dữ liệu từ RAM nhanh hơn nhiều so với đọc dữ liệu từ thiết bị lưu trữ ngoại vi. Theo nghiên cứu cho thấy, ở hầu hết các phần mềm hiện nay, ta thường làm việc với dữ liệu gần đây hơn là những dữ liệu lâu cũ; vì vậy, ta muốn dùng một shard key nào đó mà phân chia được dữ liệu gần đây để tiện việc đọc ra. Đa phần mọi người sẽ nghĩ ngay đến việc dùng tem thời gian (timestamp) hay trường ObjectId nhưng điều này không mang lại kết quả như mong đợi, ta cùng xem ví dụ sau: Giả sử ta đang quản lý dịch vụ like của facebook, mỗi document sẽ lưu hai trường

  • Ai là người gửi
  • Khi nào nó được gửi

Vấn đề như sau: Bắt đầu bằng một shard (-∞, ∞) – và dùng shard key là timestamp, dữ liệu thêm mới sẽ vào shard này và đến một lúc nào đó dữ liệu tăng lên sẽ chia thành hai shard (-∞, 1000) và [1000, ∞). Dữ liệu thêm mới sẽ nhảy vào shard [1000, ∞). Đến một lúc nào đó, shard này lại chia thành hai [1000, 3000) và [3000, ∞). Dữ liệu thêm mới lại chỉ vào shard [3000, ∞) . . . Tuy có ưu điểm là khi làm việc, ta thường làm việc với shard cuối cùng – chứa nhiều dữ liệu gần đây nhưng nhược điểm lại lấn át bởi vì dữ liệu thêm mới chỉ thêm vào shard cuối cùng và quan trọng là shard đó luôn luôn phải chia ra. Điều này sinh ra các dòng dữ liệu chuyển qua lại lãng phí giữa các shard.

2.4.3.1.3. Random Shard Key

Để tránh nhược điểm trên, ta lại chọn cách thức chọn shard key mới: ngấu nhiên. Mới đầu làm việc tốt nhưng dữ liệu tăng lên, hệ thống hoạt động càng ngày càng chậm đi. Giả sử ta muốn lưu ảnh của một website vào CSDL, Mỗi document gồm có:

  • Định dạng nhị phân của ảnh
  • Hash MD5 của ảnh
  • Một chú thích ảnh
  • Ngày lưu bức ảnh được chụp
  • Ai chụp nó

Tiến hành chọn trường Hash MD5 để làm shard key. Càng ngày, dữ liệu lớn dần lên và chúng ta có một loạt các chunk phân bố đồng đều trên các shard. Giả sử rằng, Shard 2 đang có nhiều hơn Shard 1 10 chunk và phải cân bằng. MongoDB lúc này sẽ load ngẫu nhiên 5 chunk để chuyển. Do chúng phân bố ngẫu nhiên nên việc lấy dữ liệu này không thông qua đánh index. Một lượng lớn công sức sẽ phải bỏ ra để chuyển dữ liệu (qua RAM, qua IO,…). Chính vì để ngẫu nhiên, không đánh index nên việc truy vấn dữ liệu diễn ra chậm

2.4.3.1.4. Good Shard Key

Rút cuộc, câu chuyện của ta là phải chọn một shard key sao cho nó đảm bảo tính chia nhỏ được của khoảng dữ liệu nhưng không nhỏ tới mức biến nó thành nhược điểm. Kết hợp ascending key + search key Đa phần chúng ta chỉ làm việc với các dữ liệu gần đây, nên việc chia khoảng bằng date/time là hợp lý và phân bố khá đều. Chúng ta áp dụng điều này bằng cách sử dụng cặp shard key – một loại key khác (như ascending key dạng thô, search key) Giả sử rằng ta đang có một phần mềm phân tích và cần dữ liệu của tháng gần đây nhất. Ta shard trên 2 trương {month, user}.

  • Khởi đầu có 2 chunk ((-∞,-∞), (∞,∞)).
  • Khi dữ liệu nhiều lên, chia chunk thành hai ví dụ như ((-∞, -∞),(“2011-04”, “susan”))and [(“2011-04”, “susan”), (∞, ∞))
  • Tiếp tục, dữ liệu tăng lên, các chunk tiếp theo được sinh ra trong 04 – 2011 sẽ được chuyển sang shard khác, MongoDB sẽ dần dần cân bằng tải các cluster. Sang tháng 5, ta tạo ra một chunk mới – khoảng 05 – 2011. Đến tháng 06 – 2011, ta không cần đến dữ liệu của tháng 04 nữa, dữ liệu này có thể cất đi. Nhưng khi muốn xem lại lịch sử hoạt động, chúng ta không cần chia hoặc di chuyển bất kể dữ liệu gì hết (điểm yếu của random shard key)

3. Thử nghiệm

Ta sẽ thử nghiệm về việc tự động chia chunk giữa các shard như sau: Bước chuẩn bị : Ở máy chủ: tạo thư mục /data/db và /data/configdb Ở máy con(chứa các shard con): tạo thư mục /data/db a. Máy chủ: mongod –configsvr Khởi động mongoDB Server ở máy chủ chế độ chờ config b. Máy chủ: mongos –configdb 192.168.1.2 [–chunkSize 1] Thiết lập config cho máy chủ mongos để chia các chunk (192.168.1.2 đang là ip của máy chủ) Ta thiết lập –chunkSize 1 (chunk chỉ lớn 1MB) để thấy việc chuyển chunk cho nhanh (nếu không có, mặc định là 64MB) c. Các máy con: mongod –shardsvr Khởi tạo các shard ở máy con d. Máy chủ chạy mongo localhost:27017/admin > db.runCommand({addshard:”192.168.x.x:27018″}) > db.runCommand({enablesharding:”test”}) > db.runCommand({shardcollection: “test.table1”, key: {_id: 1}}); Máy chủ lần lượt add các shard vừa tạo (cổng mặc định của shard là 27018) Áp dụng sharding trên db “test”, collection “table1”, key trên trường “_id” (_id: 1 – 1 nghĩa là on – chọn trường này làm shard key) (có thể chọn nhiều trường cùng làm shard key như đã trình bày ở trên)

Mining the Social Web

Mining the Social Web

(Các bạn comment hoặc inbox cho mình, mình sẽ gửi link download)

Làm thế nào để có thể khai thác sự giàu có của dữ liệu web xã hội để biết ai đang làm cho các kết nối với ai, những gì họ đang nói về , và nơi họ đang nằm ở đâu? Với thông tin mà quyển sách này cung cấp, bạn sẽ học cách để có được , phân tích và tổng hợp dữ liệu từ tất cả các góc của các trang web xã hội , bao gồm Facebook , Twitter, LinkedIn , Google+ , GitHub , email , các trang web , và các blog .

  • Sử dụng công cụ phân tích ngôn ngữ tự nhiên (Natural Language Toolkit) , NetworkX , và các công cụ tính toán khoa học khác để mining các trang web xã hội phổ biến
  • Áp dụng kỹ thuật Text mining , chẳng hạn như phân cụm (clustering) và TF- IDF, để trích xuất ý nghĩa từ dữ liệu văn bản
  • Sử dụng D3.js để biểu diễn dữ liệu một cách linh hoạt…

Quyển sách được tổ chức thành các phần chính như sau:

Chapter 1 Mining Twitter: Exploring Trending Topics, Discovering What People Are Talking About, and More

  • Overview
  • Why Is Twitter All the Rage?
  • Exploring Twitter’s API
  • Analyzing the 140 Characters
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 2 Mining Facebook: Analyzing Fan Pages, Examining Friendships, and More

  • Overview
  • Exploring Facebook’s Social Graph API
  • Analyzing Social Graph Connections
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 3 Mining LinkedIn: Faceting Job Titles, Clustering Colleagues, and More

  • Overview
  • Exploring the LinkedIn API
  • Crash Course on Clustering Data
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 4 Mining Google+: Computing Document Similarity, Extracting Collocations, and More

  • Overview
  • Exploring the Google+ API
  • A Whiz-Bang Introduction to TF-IDF
  • Querying Human Language Data with TF-IDF
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 5 Mining Web Pages: Using Natural Language Processing to Understand Human Language, Summarize Blog Posts, and More

  • Overview
  • Scraping, Parsing, and Crawling the Web
  • Discovering Semantics by Decoding Syntax
  • Entity-Centric Analysis: A Paradigm Shift
  • Quality of Analytics for Processing Human Language Data
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 6 Mining Mailboxes: Analyzing Who’s Talking to Whom About What, How Often, and More

  • Overview
  • Obtaining and Processing a Mail Corpus
  • Analyzing the Enron Corpus
  • Discovering and Visualizing Time-Series Trends
  • Analyzing Your Own Mail Data
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 7 Mining GitHub: Inspecting Software Collaboration Habits, Building Interest Graphs, and More

  • Overview
  • Exploring GitHub’s API
  • Modeling Data with Property Graphs
  • Analyzing GitHub Interest Graphs
  • Closing Remarks
  • Recommended Exercises
  • Online Resources

Chapter 8 Mining the Semantically Marked-Up Web: Extracting Microformats, Inferencing over RDF, and More

  • Overview
  • Microformats: Easy-to-Implement Metadata
  • From Semantic Markup to Semantic Web: A Brief Interlude
  • The Semantic Web: An Evolutionary Revolution
  • Closing Remarks
  • Recommended Exercises
  • Online Resources
  • Twitter Cookbook

Chapter 9 Twitter Cookbook

  • Accessing Twitter’s API for Development Purposes
  • Doing the OAuth Dance to Access Twitter’s API for Production Purposes
  • Discovering the Trending Topics
  • Searching for Tweets
  • Constructing Convenient Function Calls
  • Saving and Restoring JSON Data with Text Files
  • Saving and Accessing JSON Data with MongoDB
  • Sampling the Twitter Firehose with the Streaming API
  • Collecting Time-Series Data
  • Extracting Tweet Entities
  • Finding the Most Popular Tweets in a Collection of Tweets
  • Finding the Most Popular Tweet Entities in a Collection of Tweets
  • Tabulating Frequency Analysis
  • Finding Users Who Have Retweeted a Status
  • Extracting a Retweet’s Attribution
  • Making Robust Twitter Requests
  • Resolving User Profile Information
  • Extracting Tweet Entities from Arbitrary Text
  • Getting All Friends or Followers for a User
  • Analyzing a User’s Friends and Followers
  • Harvesting a User’s Tweets
  • Crawling a Friendship Graph
  • Analyzing Tweet Content
  • Summarizing Link Targets
  • Analyzing a User’s Favorite Tweets
  • Closing Remarks
  • Recommended Exercises
  • Online Resources