Cách giảm dung lượng file transaction log trong SQL Server

Kiến trúc file CSDL SQL

Khi tạo một CSDL trong SQL Server, tự động sẽ sinh ra hai tệp là tệp đuôi .MDF.LDF
Thí dụ mình tạo một CSDL tên là Demo thì sẽ sinh ra: Demo.mdf và Demo_log.ldf


Khi để chế độ Recovery Model mặc định là Full hoặc Bulk-logged thì sau một thời gian sử dụng, dung lượng file log (.ldf) sẽ phình lên rất nhiều, có thể dung lượng sẽ file log sẽ gấp nhiều lần file data. Bạn có thể chuột phải vào CSDL và chọn properties để xem


Với dung lượng file log lớn như thế này vừa tốn dung lượng ổ cứng HDD, vừa làm chậm thao tác trên CSDL đó. Vì vậy chúng ta phải giảm dung lượng file log đi là điều tất yếu.

Cách giảm dung lượng file log
Cách 1. Sử dụng SQL management tool để xóa log




Cách 2. Xóa log bằng cách sử dụng câu lệnh SHRINKFILE
ALTER DATABASE [mydatabase] SET RECOVERY SIMPLE 
DBCC SHRINKFILE(<log_file_name_Log>)
ALTER DATABASE [mydatabase] SET RECOVERY FULL
Thứ tự thực hiện câu lệnh trên như sau:

  • B1. Chuyển CSDL về simple model, thì việc xóa log mới có hiệu quả.
  • B2. Chạy lệnh xóa log file
  • B3. Chuyển về Recovery Full Model để CSDL có thể thực hiện log các trạng thái


KẾT QUẢ
Sau khi thực hiện một trong hai cách trên thì dung lượng của file log của mình giảm xuống đang ngạc nhiên




PS: Các bạn nếu thấy hay thì share giúp nhé hoặc để lại comment.

Cách phân biệt giữa các loại Recovery Model trong MSSQL Server

Bài này sẽ nói về cách phân biệt giữa các loại Recovery Model trong SQL. Cách sử dụng các Mode này sao cho hiệu quả.

1. Các loại Recovery Model

Hệ quản trị cơ MSSQL Server có 3 loại Recovery model:

  1. Full, 
  2. Simple 
  3. Bulk-logged.

Khi chúng ta tạo một CSDL mới thì hệ thống tự động chọn model là: Full.

Chúng ta có thể sử dụng SQL management tool để xem như sau:
- Click chuột phải vào database, chọn Properties



- Trên cửa số thông tin về database, chọn tab Options



- Recovery Model: Full, Bulk-logged, Simple

Hoặc có thể dụng câu lệnh SQL để truy vấn
SELECT name,
       recovery_model_desc
FROM sys.databases GO

2. Cách sử dụng các loại Recovery Model

Full Recovery Model:
  • Sao lưu gần như tất cả những thay đổi trong cơ sở dữ liệu. Nên việc bạn có thể phục hồi được tất cả dữ liệu.
  • Nếu cơ sở dữ liệu có chứa nhiều nhóm tập tin, và bạn muốn khôi phục từng phần đọc / ghi filegroups thứ cấp và tùy chọn, chỉ đọc filegroups.
  • Người quản trị có thể phục hồi được cơ sở dữ liệu đến trước thời điểm db bị hỏng hóc.
  • Dung lượng file data và file log sẽ phình ra rất nhanh, và file log có thể lớn hơn rất nhiều so với file data. Dẫn đến chi phí cho phần cứng sẽ đội lên khủng khiếp.
  • Và tất nhiên khi file phình lên thì truy vấn SQL sẽ chậm đi, thao tác với CSDL cũng chậm đi. Bạn phải thường xuyên xóa bớt file log để hệ thống chạy nhanh hơn.

Bulk-Logged Recovery Model:
  • Gần như bạn có thể phục hồi mọi thứ nếu chọn Model này. Tương tự Full Recovery Model

Simple Recovery Model
  • Không tự động lưu lại những sự thay đổi của CSDL. Nên có thể mất toàn bộ dữ liệu nếu người quản trị không backup thường xuyên.
  • Do không lưu lại các thay đổi vào file log nên dung lượng file log sẽ rất nhỏ so với file data.
  • Đây là lựa chọn hợp lý cho admin có túi tiền không được rủng rỉnh.

3. Lời khuyên
Nếu dữ liệu của bạn có thể mất mát tại một số thời điểm thì nên sử dụng Simple Recovery Model, với ưu điểm là dung lượng file data và log sẽ nhỏ, nên hệ thống sẽ chạy mượt mà hơn. Tất nhiên chúng ta có thể tự tạo ra SQL Job Backup tự động cho CSDL theo thời gian để tránh mất mát dữ liệu (ngày backup 2 lần chẳng hạn) các bạn có thể tham khảo tại đây.

Chúng ta có thể thay đổi Recovery Model bằng cách sử dụng SQL Management Tool hoặc sử dụng câu lệnh sau:
USE master;


ALTER DATABASE DEMO
SET RECOVERY FULL ;

Chúc các bạn thành công khi làm việc với SQL Server.



Một ngày đi học ...


Hôm nay đi dự hội thảo Tech Insider Expo 2015 do Vietnamworks tổ chức. Qua những lời giới thiệu trong email mời hoành tráng của ban tổ chức. Sau khi tham gia hội thảo mình có một số cảm nhận như sau.

Thứ nhất, về cách thức tổ chức, lựa chọn khách mời có thể nói là tạm được. Cũng hơi buồn vì mình làm công nghệ, biết khá nhiều cao thủ nhưng khi tham dự hội thảo lại chẳng bắt gặp cao thủ nào.

Thứ hai, mình đến để tham gia hội thảo nhưng khi đến phòng hội thảo thì vừa đúng giờ chuẩn bị bắt đầu nhưng lại hết chỗ ngồi, thế là lại chưng hửng ngồi ngoài. Buồn vì với số khách mời là hơn 1.5k sao cái phòng hội thảo lại bé tý... Đành đợi buổi hội thảo vào 1h30 vậy.

Thứ ba, ghé qua các lán trại tuyển dụng, đọc thấy thông tin tuyển dụng hấp dẫn ghê (toàn công ty lớn theo như profile là những công ty top của châu á) mặc dù chưa có nhu cầu xin việc nhưng cũng thử ghé vào xem thế nào. Nhưng hơi bất ngờ vì không thấy người đến ứng tuyển mà chỉ thấy các HR đang ngồi chém gió là nhiều. Có một vài người ghé vào, đi ra với gương mặt thỏa mãn vì có quà xách về...

Phải nói ý tưởng về một Tech Insider Expo là rất hay. Nhưng cần quảng bá rộng hơn trong cộng đồng lập trình viên việt nam. Dù sao cũng rất cảm ơn Vietnamworks đã tổ chức 1 chương trình khá hay dành cho những người đang có nhu cầu tìm việc làm.

Thiết kế database theo hướng multi-tenancy, SaaS


Bài toán hướng multi-tenancy trong thực tế gặp rất nhiều, nhưng có rất nhiều developer chưa nắm được khái niệm và cách thức hoạt động của các hệ thống thiết kế theo hướng này. Qua một thời gian nghiên cứu và phát triển các hệ thống, mình đúc rút một số kinh nghiệm muốn chia sẻ cho mọi người.

Thực tế ta bắt gặp rất nhiều hệ thống sử dụng multi-tenacy
vd:
- Hệ thống quản lý cửa hàng cho phép nhiều đại lý có thể truy cập với những tài khoản độc lập, dữ liệu độc lập, nhưng cùng chung 1 hệ thống site.
- Hệ thống quản lý công văn sử dụng trong tổng công ty và nhiều công ty con, cùng site nhưng dữ liệu độc lập.
- Hệ thống quản lý dự án Jira
- Hệ thống CRM của zoho, saleforce...

Nhiều hệ thống sử dụng SQL server, Oracle ... thiết kế hệ thống multi-tenancy theo một trong các kiến trúc sau.


Phương án I. Cùng chung một cơ sở dữ liệu (database), chia sẻ bảng (table)
Ví dụ:
Một hệ thống quản lý cửa hàng, có bảng shop, bảng sản phẩm (product), bảng acccount

Bảng shop
Shop (
Id,
Name,
Notes)

Bảng user
User(
Id,
Name,
UserName,
Password,
ShopId
)
Bảng product
Product (
Id int,
Code varchar(50),
Name varchar(255),
ShopId)

Tất cả các bảng liên quan đều có 1 khóa ngoại là ShopId. Dữ liệu sản phẩm của từng shop đều được lưu chung trong bảng Product, nhưng được phân biệt nhau bởi trường ShopId.

Điểm mạnh:
- Thiết kế lưu trữ đơn giản.
- Dễ cho việc phát triển.
- Không gặp phải vấn đề đồng bộ cấu trúc bảng trong quá trình phát triền.

Nhược điểm:
- Không độc lập database nên việc một shop có thể xem dữ liệu của shop khác nếu có quyền truy cập SQL, phân quyền trên SQL thực sự là vấn đề lớn.
- Vấn đề backup, restore dữ liệu cho từng shop là gần như không thể, chỉ có thể backup cho tất cả.
- Vấn đề phát sinh thực sự phức tạp khi dữ liệu phình to, rất khó khăn trong việc backup, restore...
- Khó khăn khi scale hệ thống.

Lời khuyên: Phương án này chỉ dùng làm những hệ thống nhỏ, ít dữ liệu, phát sinh dữ liệu không lớn.


Phương án II. Cùng chung database, chia sẻ schema
Hướng thiết kế này sử dụng một cơ sở dữ liệu, mỗi tenant tương ứng 1 schema. Có một schema chung để quản lý những các dữ liệu chung, quản lý thông tin về tenants. Cấu trúc các bảng ở tất cả các tenant đều giống nhau.
Cần 1 schema chuẩn để dựa vào đó tạo ra tenant mới trong quá trình thêm mới tenant.

Điểm mạnh:
- Thiết kế theo hướng này thì có thê thay đổi các cấu trúc, hàm, thủ tục riêng rẽ giữa các tenant.
- Dễ phân quyền hơn phương án 1.
- Tiết kiệm được chi phí khi triển khai (do số lượng database chỉ là rất ít)

Nhược điểm:
- Phương án backup độc lập từng tenant là vấn đề nan giải, lập trình viên sẽ phải tự quản lý việc backup/restore cho từng tenant bằng code.
- Việc đồng bộ những thay đổi trong cấu schema là vấn đề cần phải quan tâm.
- Dữ liệu trong database sẽ phình ra nhanh chóng.
- Số lượng schema trong 1 database là có giới hạn.
- Khó khăn khi scale hệ thống.


Phương án III. Mỗi tenant một database.

Phương án này sẽ thực hiện như sau: hệ thống sẽ gồm 1 database chung (chuyên để quản lý các phần như danh sách tenant, user, role ...), 1 database tenant chuẩn (chứa dữ liệu chuẩn), và các tenant khác.
Mỗi tenant sẽ là 1 database, người dùng sẽ có quyền truy cập vào database chung và database tenant của user đó.

Mình sẽ đính kèm script sql server để tạo databases cho các phương án trên, phương án 3 giống như phương án 2, nhưng thay vì dùng schema thì chuyển sang dùng database.

SQL Script Mutil-tenancy












SQL Tips: Hướng dẫn sử dụng SQL Profiler


Microsoft SQL Server Profiler là một công cụ hỗ trợ DBA giám sát câu lệnh query thực thi (T-SQL Statements ) của Database Engine. DBA có thể lưu lại thông tin về các câu lệnh đã thực thi để sử dụng về sau.

System requirement: SQL Server Enterprise (2005/2008/2012...).

Step1. Mở SQL Server profiler 

Path: Start | All Programs | Microsoft SQL Server 2012| Performance Tools | SQL Server Profiler


Step 2. Tạo một SQL Server Profiler Trace


Step 3. Connect to SQL Server


Step 4. Điền thông tin Trace

General Tab
- Trace Name
- Save to file: Lưu thông tin trace vào một file.
- Save to table: Lưu thông tin trace vào 1 bảng trong SQL do người dùng chỉ định.



Events Selection Tab


DBA có thể sử dụng nhưng thông tin mặc định. Hoặc có thể chỉnh sửa filter theo nhu cầu.
Để lựa chọn filter phù hợp, hãy click chọn Column Filters..

- Nhập tên ứng dụng đang sử dụng SQL.


- Nhập text bạn muốn filter


Sau khi điền thông tin, chọn OK.

Bước 5. Tiếp  tục Click on Run button.


Khi một ứng dụng bất kỳ truy cập, thực thi câu lệnh SQL, trên giao diện trace sẽ hiển thị thông tin câu lệnh đó.


Chúc mọi người sớm thành thạo SQL Server Profiler

SQL Tips: Create SQL Job to backup database everyday


Today, I will make a backup manual database daily work by creating SQL Job.
First we have to install the SQL Server Agent SQL.
Set mode to run automatically when Windows startup.

Step 1.

- Setup SQL Server Agent
- Run Sql Server Agent services




Step 2.
- Create database: "Demo"
- Create store procedure jb_Backup_Database


-- =============================================
-- Author:  Phuong Nguyen
-- Create date: YYYY-MM-DD
-- Description: Backup database
-- =============================================
ALTER PROCEDURE [dbo].[jb_Backup_Database]
 
AS
BEGIN
 
 DECLARE @DBName  NVARCHAR(50) -- database name  
 DECLARE @BKPath  NVARCHAR(256) -- path for backup files  
 DECLARE @BKFileName NVARCHAR(256) -- filename for backup  
 DECLARE @BKFileDate NVARCHAR(20) -- used for file name

 -- Set dbname is current db
 SET @DBName  = DB_NAME()

 -- Database backup directory
 SET @BKPath  = 'C:\DB\Backup\'  
  
 -- Filename format
 SELECT @BKFileDate = CONVERT(NVARCHAR(20),getDate(),112) 
 SET @BKFileName = @BKPath + @DBName + '_' + @BKFileDate + '.BAK'  
 
 BACKUP DATABASE @DBName TO DISK = @BKFileName  

END

- Run proc to test result
exec jb_Backup_Database

Create backup file successful



Step 3. Create Job call store procedure

- Create Job with job name "jb_Backup_database_demo"


- Create Step for database "Demo" with command: exec jb_Backup_Database

- Schedule Job

After create job, enable job.

You can run job to test result.

SQL Script:
USE [msdb]
GO

/****** Object:  Job [jb_Backup_database_demo]    Script Date: 6/28/2015 4:18:14 PM ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object:  JobCategory [[Uncategorized (Local)]]]    Script Date: 6/28/2015 4:18:14 PM ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'jb_Backup_database_demo', 
  @enabled=1, 
  @notify_level_eventlog=0, 
  @notify_level_email=0, 
  @notify_level_netsend=0, 
  @notify_level_page=0, 
  @delete_level=0, 
  @description=N'No description available.', 
  @category_name=N'[Uncategorized (Local)]', 
  @owner_login_name=N'sa', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
/****** Object:  Step [RunBackupDemo]    Script Date: 6/28/2015 4:18:15 PM ******/
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'RunBackupDemo', 
  @step_id=1, 
  @cmdexec_success_code=0, 
  @on_success_action=1, 
  @on_success_step_id=0, 
  @on_fail_action=2, 
  @on_fail_step_id=0, 
  @retry_attempts=0, 
  @retry_interval=0, 
  @os_run_priority=0, @subsystem=N'TSQL', 
  @command=N'exec jb_Backup_Database', 
  @database_name=N'Demo', 
  @flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'Everyday', 
  @enabled=1, 
  @freq_type=4, 
  @freq_interval=1, 
  @freq_subday_type=1, 
  @freq_subday_interval=0, 
  @freq_relative_interval=0, 
  @freq_recurrence_factor=0, 
  @active_start_date=20150627, 
  @active_end_date=99991231, 
  @active_start_time=234700, 
  @active_end_time=235959, 
  @schedule_uid=N'624f7aee-128d-403b-8037-4bde1c1a792d'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

GO

You are created Job to backup database everyday.

Good luck


SQL Tips: Những phím tắt sử dụng trong SQL nên biết


SQL server Management Studio hỗ trợ rất nhiều phím tắt, sau đây là một số phím tắt đặc biệt.
1. Mở cửa sổ query mới (Ctrl + N)
Tổ hợp phím này sẽ giúp bạn mở cửa sổ mới một cách nhanh chóng
SQL_Server_New_Window_Keyboard_Shortcut
2. Hiển thị các cửa sổ SQL đang làm việc (Ctrl + Tab)
Tổ hợp phím này sẽ hỗ trợ cho việc hiển thị tất cả các cửa sổ đang làm việc.
sql_server_toogle_tabs_keyboard_shortcut
3. Ẩn hiện kết quả câu lệnh (Ctrl + R)
Khi muốn ẩn kết quả câu query thì bạn chỉ cần nhần tổ hợp phím Ctrl + R
SQL_server_keyboard_shortcuts_show_hide_results_pane
4. Chạy câu lệnh SQL đang được chọn (Ctrl + E)
Tổ hợp phím Ctrl + E sẽ giúp bạn chạy câu query đang được chọn
SQL_server_shortcuts_Execute_highlighted_query
5. Hủy bỏ câu query  đang chạy (Alt + Break or Alt + Scroll Lock)
Trường hợp câu query của bạn đang chạy mất quá nhiều thời gian, bạn có thể sử dụng tổ hợp phím này để hủy bỏ nhanh chóng.
SQL_Server_Cancel_executing_query
6. Chuyển câu lệnh đang chọn thành chữ hoa, chữ thường (Ctrl + Shift + U, Ctrl + Shift + L)
SQL_Server_Make selected text as Uppercase_lowercase
7. Hiển thị quá trình chạy câu query (Ctrl + L)
Hiển thị quá trình chạy câu query  với tổ hợp Ctrl + L
SQL_server_display_estimated_execution_plan_keyboard_shortcut
8. Hiển thị kết quả cùng quá trình chạy câu query (Ctrl + M)
sql_server_include_actual_execution_plan_shortcut
9. Gợi ý những câu lệnh, bảng ... (Ctrl + Space, Tab)
sql_server_Intellisense_keyboard_shortcut
10. Chuyển nhanh đến dòng (Ctrl + G)
Bạn có thể chuyển nhanh đến dòng code bao nhiêu băng cách dùng tổ hợp Ctrl + G
Sql_server_keyboard_shortcuts_go_to_line
11. Comment và bỏ comment dòng lệnh ( Ctrl + K & Ctrl + C; Ctrl + K & Ctrl + U)
sql_server_comment_uncomment_code

16 BÀI HỌC CẦN GHI NHỚ


Bài học số 01

Hai con bồ câu trống và mái tha hạt thóc về đầy tổ, cả hai rất ư hạnh phúc. Gặp mùa khô hanh, hạt thóc ngót lại. Con trống thấy tổ vơi đi liền trách con mái ăn vụng. Con mái cãi lại liền bị con trống mổ chết. Mấy hôm sau mưa xuống, hạt thóc thấm nước và nở to ra. Bồ câu trống đau khổ mà ngẩn ngơ mà đau xót ngậm ngùi vì mình hại chết vợ mình.
Bài học rút ra: “thịt” nhân viên một cách hồ đồ không làm bạn trông thông minh hơn.

Bài học số 02

Một ông vua nọ do chán chuyện triều đình nên mua một con khỉ đem về. Con khỉ làm trò rất hay nên được vua sủng ái, đi đâu cũng mang theo, cho mặc quần áo, giao cả kiếm cho giữ. Một hôm, vua ra vườn thượng uyển ngủ. Có con ong bay đến đậu lên đầu vua. Khỉ muốn đuổi ong, lấy kiếm nhắm vào ong mà chém. Đức vua băng hà.
Bài học rút ra: trao quyền cho những kẻ không có năng lực thì luôn phải cẩn thận và cảnh giác.

Bài học số 03

Quạ thấy chó ngậm khúc xương quá ngon, bèn đánh liều lao xuống mổ vào đầu chó. Bị bất ngờ, chó bỏ chạy để lại khúc xương. Quạ ngoạm lấy khúc xương nhưng nặng quá không tha nổi. Chó, sau khi hoàn hồn, thấy kẻ tấn công chỉ là con quạ nên quay lại táp một cú, quạ chết tươi.
Bài học rút ra: đừng ghen anh tức ở quá với những miếng mồi ngon của kẻ khác. Ghen tức vì người ta có miếng mồi ngon nhưng cũng phải biết nó phù hợp với mình không để mà bõ công chứ. Nếu không cũng sôi hỏng bỏng không cả thôi.

Bài học số 04

Ba con thú dữ là sói, gấu và cáo thay nhau ức hiếp đàn dê. Dê đầu đàn bèn nói với cả bầy: “Ta nên mời một trong ba gã sói, gấu hay cáo làm thủ lĩnh của chúng ta”. Cả đàn dê bất bình, nhưng ba “hung thần” nghe tin này rất mừng. Thế là chúng quay sang tranh giành nhau quyền lãnh đạo, cuối cùng cáo dùng bẫy hại chết được sói và gấu. Nhưng rồi một mình nó không còn ức hiếp đàn dê được nữa.
Bài học rút ra: hãy thận trọng khi nghe tin bạn sắp được làm sếp. Không phải làm sếp là sung sướng đâu. Có thể đó cũng là cái bẫy để hãm hại chính bạn.

Bài học số 05

Một nhân viên bán hàng, một thư ký hành chính và một sếp quản lý cùng đi ăn trưa với nhau, họ bắt được một cây đèn cổ. Họ xoa tay vào đèn và thần đèn hiện lên. Thần đèn bảo: “Ta cho các con mỗi người một điều ước”. Tôi trước! Tôi trước! – Cô thư ký hành chính nhanh nhảu nói: Tôi muốn giàu sang phú quý và quên hết sự đời. Vút. Cô thư ký biến mất. Tôi! Tôi! anh nhân viên bán hàng nói: Tôi muốn ở Hawaii nằm dài trên bãi biển có nhân viên massage riêng, nguồn cung cấp Pina Coladas vô tận và với người tình trăm năm. Vút. Anh nhân viên bán hàng biến mất. Ok tới lượt anh. Thần đèn nói với ông quản lý. Ông quản lý nói: tôi muốn hai đứa ấy có mặt ở văn phòng làm việc ngay sau bữa trưa.
Bài học xương máu: luôn luôn để sếp phát biểu trước. Đừng có mơ bạn vượt mặt nhé.
Bài học số 06
Một con đại bàng đang đậu trên cây nghỉ ngơi, chẳng làm gì cả. Con thỏ nhìn thấy thế hỏi: Tôi có thể ngồi không và chẳng làm gì như anh được không? Ðại bàng trả lời: Được chứ, sao không. Thế là con thỏ ngồi xuống gốc cây nghỉ ngơi. Bỗng dưng một con cáo xuất hiện, vồ lấy con thỏ mà ăn thịt.
Bài học xương máu: để được ngồi không mà chẳng cần làm gì, anh phải ngồi ở vị trí rất cao. Nếu không sớm muộn gì bạn cũng chỉ là miếng mồi ngon cho kẻ khác thôi

Bài học số 07

Một con gà tây trò chuyện với một con bò:
“Giá mà tôi có thể bay lên ngọn cây kia thì thích quá, nhưng tôi không đủ sức”, gà tây thở dài.
“Được rồi, tại sao bạn không nếm tý “chất thải” của tôi nhỉ? Nó có nhiều chất bổ lắm đấy”, bò trả lời . Gà tây mổ ăn chất thải của con bò và nó thấy quả là nó đã đủ sức bay lên cái cành thấp nhất. Ngày hôm sau, ăn thêm chút nữa, nó bay lên được cành thứ hai. Cuối cùng, sau đêm thứ tư, gà tây khoái chí lên tới được ngọn cây. Nó lập tức bị một nông dân phát hiện, anh này bắn nó rơi xuống đất.
Bài học xương máu: sự ngu ngốc có thể đưa bạn lên đỉnh cao nhưng đừng tưởng bở, sớm hay muộn bạn cũng bị hạ gục thôi. 

Bài học số 08

Một con chim nhỏ bay về phương Nam tránh rét. Trời lạnh quá con chim bị lanh cứng và rơi xuống một cánh đồng lớn. Trong lúc nó nằm đấy, người nông dân không để ý đã lấp bùn đất bẩn thỉu lên người chú chim nhỏ bé. Con chim nằm giữa đống bùn nhận ra rằng nó đang ấm dần. Ðống bùn bẩn đã ủ ấm cho nó. Nó nằm đấy thấy ấm áp và hạnh phúc, nó bắt đầu cất tiếng hót yêu đời. Một con mèo đi ngang, nghe tiếng chim hót liền tới thám thính. Lần theo âm thanh, con mèo phát hiện ra con chim nằm trong đống bùn bẩn, nó liền kéo con chim ra ăn thịt.
Bài học xương máu:
  1. không phải thằng nào hết bùn đất bẩn vào người mình cũng là kẻ thù của mình
  2. không phải thằng nào kéo mình ra khỏi đống bùn đất bẩn cũng là bạn mình
  3. và khi đang ngập ngụa trong đống bùn đất bẩn thì tốt nhất là ngậm cái mồm lại.

Bài học số 09

Một tu-sĩ nam ngỏ ý mời tu-sĩ nữ đi chung xe. Người nữ chui vào xe, ngồi bắt chéo chân để lộ 1 bên bắp chân. Người nam suýt nữa thì gây tai nạn. Sau khi điều chỉnh lại tay lái, người nam thò tay mò mẫm lên đùi người nữ. Nữ kêu: “Xin ngài, hãy nhớ điều răn 129″. Nam liền bỏ tay ra. Nhưng sau khi vào số, nam lại tiếp tục sờ soạng chân nữ. Một lần nữa nữ kêu: “Xin ngài, hãy nhớ điều răn 129″. Nam thẹn quá: “xin lỗi nữ, tôi trần tục quá”. Tới nơi, nữ thở dài và bỏ đi.
Vừa tới nhà tu, nam vội chạy vào thư viện tra cứu ngay cái điều răn 129 ấy, thấy đề: “Hãy tiến lên, tìm kiếm, xa hơn nữa, con sẽ tìm thấy hào quang.”
Bài học xương máu:
Nếu anh không nắm rõ thông tin trong công việc của mình anh sẽ bỏ lỡ 1 cơ hội lớn.

Bài học số 10

Ông chồng đi tắm sau khi vợ vừa mới tắm xong, đúng lúc chuông cửa reo. Vợ vội quấn khăn tắm vào và chạy xuống mở cửa. Cửa mở thì ra là ông hàng xóm Bob. Chị vợ chưa kịp nói gì thì Bob bảo: tôi sẽ cho chị 800 đô nếu chị buông cái khăn tắm kia ra . Suy nghĩ 1 chút rồi chị vợ buông khăn tắm, đứng trần truồng trước mặt Bob. Sau vài giây ngắm nghía, Bob đưa 800 đô cho chị vợ rồi đi. Chị vợ quấn lại khăn tắm vào người rồi đi lên nhà.
– Vào đến phòng tắm, chồng hỏi: Ai đấy em?
– Vợ: ông Bob hàng xóm.
– Chồng: Tốt. thế hắn có nói gì đến số tiền 800 đô hắn nợ anh không?
Bài học xương máu:
Nếu anh trao đổi thông tin với nhân viên  của mình kịp thời thì anh đã có thể ngăn được sự “phơi bày” với những người ngoài
  Bài học số 11
Chàng yêu nàng từ thuở nàng mười lăm mười sáu tuổi. Cả hai lén lút đi lại, quan hệ, quậy gia đình, trốn nhà đi, dọa chết nếu không được chấp nhận. Nếu quan hệ ấy kéo dài một năm, được gọi là phạm pháp, dụ dỗ trẻ vị thành niên, có nguy cơ ra tòa thụ án. Nếu mối tình ấy kéo dài ba năm, được gọi là yêu trộm, tình yêu oan trái. Nếu mối tình kéo dài sáu bảy năm, sẽ được gọi là tình yêu đích thực, vượt núi trèo đèo qua bao khó khăn để yêu nhau.
Kết luận: Bạn làm gì chả quan trọng, quan trọng là bạn làm được trong… bao lâu!

Bài học số 12

Một nàng cave, nếu ngủ với thợ thuyền hoặc lao động ngoại tỉnh, thì bị gọi là đối tượng xã hội. Nếu ngủ với đại gia lừng lẫy, thì được gọi là chân dài. Nếu ngủ với một ngôi sao sân cỏ hoặc màn bạc, sẽ được đàng hoàng lên báo kể chuyện “nghề nghiệp” và trưng ảnh hở da thịt giữa công chúng, không ai có ý định bắt nàng.
Kết luận: Bạn làm gì chả quan trọng, quan trọng là bạn làm điều đó với ai, bạn kiếm được bao nhiêu tiền.

Bài học số 13

Phòng tắm công cộng bỗng dưng bị chập điện gây hỏa hoạn lớn, vô số chị em chạy túa ra đường mà không kịp mặc gì. Những nàng thông minh là người không lấy tay che thân thể, mà lấy tay che… mặt.
Kết luận: Hãy quan tâm tới mấu chốt của mọi vấn đề. Đừngbao giờ nghĩ ngắn quá mà học cách nhìn xa trông rộng trong từng tình huống

Bài học số 14

Một nàng gái ế chạy tới đồn cảnh sát tố cáo: “Tôi đã cẩn thận để tiền trong áo lót, thế mà thằng cha đẹp trai đứng cạnh tôi ở trên xe bus đông đúc đã móc lấy mất tiền của tôi!”. Cảnh sát ngạc nhiên: “Tại sao nó có thể móc tiền được ở một vị trí “nhạy cảm” như thế, mà cô không phát hiện ra?”
Cô nàng gái ế thút thít: “Ai ngờ được là nó chỉ muốn moi tiền?”
Kết luận: Một nhà quản trị kinh doanh tài ba là người moi được tiền của khách hàng trong lúc đang khiến khách hàng sung sướng ngất ngây.

Bài học số 15

Nhân viên vệ sinh của công ty rất buồn phiền vì các quý ông thường lơ đãng khi vào nhà vệ sinh. Để giải quyết những vũng nước vàng khè dưới nền toilette, công ty dán lên tường, phía trên bệ xí nam một tờ giấy: “Không tiểu tới bô chứng tỏ bạn bị ngắn, tiểu ra ngoài bô chứng tỏ bạn bị… ủ rũ!”. Ngay từ ngày hôm sau, toilette nam sạch bóng và không còn quý ông nào lơ đãng nữa.
Kết luận: Hãy chứng minh cho khách hàng thấy vấn đề một cách cụ thể, ấn tượng nhất khiến họ không bao giờ quên.

Bài học số 16

Bố mẹ nàng mở cuộc thi tuyển con rể. Chàng A nói, tài khoản có một triệu đô. Chàng B khoe, có biệt thự hai triệu đô. Bố mẹ nàng có vẻ ưng lắm. Chàng C nói, cháu chả có gì cả, thưa các bác. Cháu chỉ có mỗi một đứa con, hiện đang nằm trong bụng của con gái các bác!
Kết luận: Muốn cạnh tranh với đối thủ, cần có tay trong!
Nguồn: sưu tầm

SQL Tip: Quy tắc sử dụng thủ tục sp_executesql?


Đối với các câu lệnh sử dụng thủ tục sp_executesql thì chúng ta cần lưu ý một số vấn đề sau:

Phải khai báo biến kiểu Nvarchar để tránh lỗi
Câu lệnh sai
DECLARE @SQL VARCHAR(100)
SET @SQL = 'SELECT TOP 1 * FROM sys.tables'
EXECUTE sp_executesql @SQL
Câu lệnh đúng:
DECLARE @SQL NVARCHAR(100)
SET @SQL = 'SELECT TOP 1 * FROM sys.tables'
EXECUTE sp_executesql @SQL

Giới thiệu về cơ sở dữ liệu NoSQL




Trong vài năm qua chúng ta đã thấy sự gia tăng của một loại cơ sở dữ liệu mới, đó là cơ sở dữ liệu NoSQL - mà đang thách thức sự thống trị của cơ sở dữ liệu quan hệ. Cơ sở dữ liệu quan hệ đã thống trị ngành công nghiệp phần mềm trong một thời gian dài khi đã cung cấp cơ chế để lưu trữ dữ liệu liên tục, đồng thời kiểm soát, giao dịch, giao diện được chuẩn hóa và được tích hợp vào các hệ thống dữ liệu ứng dụng, báo cáo. Tuy nhiên, ưu thế đó đã không còn tồn tại cho cơ sở dữ liệu quan hệ nữa.

NoSQL nghĩa là gì?

NoSQL có nghĩa là gì và làm thế nào để phân loại các cơ sở dữ liệu? NoSQL có nghĩa là Không Chỉ SQL, ngụ ý rằng khi thiết kế một giải pháp phần mềm hoặc sản phẩm, có nhiều hơn một cơ chế lưu trữ có thể được sử dụng dựa trên các nhu cầu. NoSQL không có một định nghĩa rõ ràng mà chúng ta có thể hiểu là mô hình cơ sở dữ liệu mới có các đặc điểm như sau:
  • Không sử dụng các mô hình quan hệ
  • Chạy tốt trên các cụm(server)
  • Chủ yếu là mã nguồn mở
  • Xây dựng cho web thế kỷ 21
  • Tối thiểu hóa lược đồ

Tại sao lại là NoSQL?


Chúng ta sẽ gặp vấn đề khó khăn khi có sự không tương ứng giữa cấu trúc dữ liệu quan hệ và cấu trúc dữ liệu được lưu trong bộ nhớ hệ thống. Tuy nhiên, sử dụng  NoSQL cho phép chúng ta tiếp tục phát triển mà không cần chuyển đổi cấu trúc lưu trong bộ nhớ với cấu trúc dữ liệu quan hệ.
Sự gia tăng của các trang web cũng tạo ra một sự thay đổi quan trọng trong việc lưu trữ dữ liệu như sự cần thiết để hỗ trợ khối lượng dữ liệu lớn bằng cách chạy trên các cụm. Tuy nhiên, cơ sở dữ liệu quan hệ không được thiết kế để hoạt động hiệu quả trên các cụm. Ví dụ, các nhu cầu lưu trữ dữ liệu của một ứng dụng ERP là rất nhiều khác biệt so với nhu cầu lưu trữ dữ liệu của một Facebook hoặc một Etsy.

Mô hình dữ liệu tổng hợp

Mô hình cơ sở dữ liệu quan hệ là rất khác nhau so với các loại cấu trúc dữ liệu mà các nhà phát triển ứng dụng sử dụng. Sử dụng các cấu trúc dữ liệu đã được mô hình hóa bởi các nhà phát triển để giải quyết vấn đề, lĩnh vực khác nhau đã làm tăng chuyển động đi từ mô hình quan hệ và hướng tới mô hình tổng hợp (hầu hết trong số này được đề cập đến trong cuốn sách Domain Driven Design của Eric Evans). Một số mô hình là tổng hợp của các đơn vị dữ liệu mà chúng ta tương tác với từng phần trong đó. Các đơn vị dữ liệu với cơ sở dữ liệu như là key-value, 'document', và 'column-family'.
Tổng hợp làm cho chúng ta dễ dàng hơn trong việc quản lý dữ liệu lưu trữ trên các cụm. Và các đơn vị dữ liệu bây giờ có thể lư trữ trên bất kỳ máy tính nào và khi lấy ra từ cơ sở dữ liệu chúng ta sẽ được tất cả các dữ liệu có liên quan cùng với nó. Cơ sở dữ liệu tổng hợp làm việc tốt nhất khi hầu hết các dữ liệu được thực hiện trên cùng một tổng hợp, ví dụ như khi cần có được một đơn đặt hàng và tất cả các chi tiết của nó, nó sẽ tốt hơn khi lưu trữ thông tin theo một đối tượng tổng hợp.

Mô hình phân tán:

Cơ sở dữ liệu theo định hướng tổng hợp thực hiện phân phối các dữ liệu dễ dàng hơn, vì các cơ chế phân phối có để di chuyển tổng hợp và không phải lo lắng về dữ liệu có liên quan, như tất cả các dữ liệu liên quan được chứa trong tổng hợp. Có hai kiểu phân phối dữ liệu:
Sharding: sharding phân phối dữ liệu khác nhau trên nhiều máy chủ, do đó mỗi máy chủ đóng vai trò như là nguồn duy nhất cho một tập hợp con của dữ liệu. Replication: replication sao chép dữ liệu trên nhiều máy chủ, vì vậy mỗi bit dữ liệu có thể được tìm thấy ở nhiều nơi. Replication có hai hình thứ
  • Master-slave: làm cho một nút có quyền hạn như là bản sao để xử lý ghi trong khi slave đồng bộ với master và có thể xử lý đọc.
  • Peer-to-peer: cho phép ghi vào bất kỳ nút nào mà các nút phối hợp đồng bộ các bản sao của dữ liệu
Master-slave làm giảm sự xung đột khi có thực hiện cập nhật còn peer-to-peer tránh tải tất cả viết lên một máy chủ duy nhất nên khi có lỗi chỉ xảy ra tại một điểm duy nhất. Một hệ thống có thể sử dụng một trong hai hoặc cả hai kỹ thuật trên.

Phân loại cơ sở dữ liệu NoSQL

NoSQL được chia làm 4 loại sau:

Loại key-value:

Lưu trữ kiểu key-value là kiểu lưu trữ dữ liệu NoSQL đơn giản nhất sử dụng từ một API. Chúng ta có thể nhận được giá trị cho khóa, đặt một giá trị cho một khóa, hoặc xóa một khóa từ dữ liệu. Ví dụ, giá trị là ‘blob’ được lưu trữ thì chúng ta không cần quan tâm hoặc biết những gì ở bên trong. Từ các cặp giá trị được lưu trữ luôn luôn sử dụng truy cập thông qua khóa chính và thường có hiệu năng truy cập tốt và có thể dễ dàng thu nhỏ lại.
Một vài cơ sở dữ liệu key-value phổ biến là Riak, Redis(thường dùng phía server), memcached, Berkeley DB, HamsterDB, Amazon DynamoDB(mã nguồn đóng), Project Voldemort và Couchbase.
Tất cả các cơ sở dữ liệu kiểu key-value đều không giống nhau, có rất nhiều điểm khác nhau giữa các sản phẩm. Ví dụ, dữ liệu của memcached không được nhất quán trong khi ngược lại với Riak. Đấy là những điểm nổi bật quan trọng khi chọn giải pháp phù hợp để sử dụng. Cụ thể hơn là khi chúng ta cần cài đặt caching cho nội dung yêu thích của người dùng, cài đặt sử dụng memcached có nghĩa là khi các nút hỏng hết dẫn tới dữ liệu bị mất và cần phải làm mới lại từ hệ thống nguồn. Tuy nhiên, nếu chúng ta lưu trữ cùng dữ liệu đó trong Riak, chúng ta không cần lo lắng về việc mất dữ liệu nhưng cần phải xem xét việc cập nhật trạng thái của dữ liệu như thế nào. Điều này là quan trọng không chỉ cho chọn cơ sở dữ liệu key-value cho hệ thống và còn quan trọng cho việc chọn cơ sở dữ liệu key-value nào.

Cơ sở dữ liệu tài liệu (Document databases)

Tài liệu là nguyên lý chính của cơ sở dữ liệu kiểu dữ liệu. Dữ liệu lưu trữ và lấy ra là các tài liệu với định dạng XML, JSON, BSON,… Tài liệu miêu tả chính nó, kế thừa từ cấu trúc dữ liệu cây. Có thể nói cơ sở dữ liệu tài liệu là 1 phần của key-value. Cơ sở dữ liệu kiểu tài liệu như MongoDB cung cấp ngôn ngữ truy vấn đa dạng và cúc trúc như là cơ sở dữ liệu như đánh index,…
Một số cơ sở dữ liệu tài liệu phổ biến mà chúng ta hay gặp là MongoDB, CouchDB, Terastore, OrientDB, RavenDB.

Cơ sở dữ liệu ‘column family’


Cơ sở dữ liệu column-family lưu trữ dữ liệu trong nhiều cột trong mỗi dòng với key cho từng dòng. Column families là một nhóm các dữ liệu liên quan được truy cập cùng với nhau. Ví dụ, với khách hàng, chúng ta thường xuyên sử dụng thông tin cá nhân trong cùng một lúc chứ không phải hóa đơn của họ.
Cassandra là một trong số cơ sở dữ liệu column-family phổ biến. Ngoài ra còn có một số cơ sở dữ liệu khác như HBase, Hypertable và Amazon DynamoDB. Cassandra có thể được miêu tả nhanh và khả năng mở rộng dễ dàng với các thao tác viết thông qua các cụm. Các cụm không có node master, vì thế bất kỳ việc đọc và ghi nào đểu có thể được xử lý bởi bất kỳ node nào trong cụm.

Cơ sở dữ liệu đồ thị


Kiểu đồ thị này cho phép bạn lưu trữ các thực thể và quan hệ giữa các thực thể. Các đối tượng này còn được gọi là các nút, trong đó có các thuộc tính. Mỗi nút là một thể hiện của một đối tượng trong ứng dụng. Quan hệ được gọi là các cạnh, có thể có các thuộc tính. Cạnh có ý nghĩa định hướng; các nút được tổ chức bởi các mối quan hệ. Các tổ chức của đồ thị cho phép các dữ liệu được lưu trữ một lần và được giải thích theo nhiều cách khác nhau dựa trên các mối quan hệ.
Thông thường, khi chúng ta lưu trữ một cấu trúc đồ thị giống như trong RDBMS, nó là một loại duy nhất của mối quan hệ. Việc tăng thêm một mối quan hệ có nghĩa là rất nhiều thay đổi sơ đồ và di chuyển dữ liệu, mà không phải là trường hợp khó khi chúng ta đang sử dụng cơ sở dữ liệu đồ thị. Trong cơ sở dữ liệu đồ thị, băng qua các thành phần tham gia hoặc các mối quan hệ là rất nhanh. Các mối quan hệ giữa các node không được tính vào thời gian truy vấn nhưng thực sự tồn tại như là một mối quan hệ. Đi qua các mối quan hệ là nhanh hơn so với tính toán cho mỗi truy vấn.
Có rất nhiều cơ sở dữ liệu đồ thị có sẵn, chẳng hạn như Neo4J, Infinite Graph, OrientDB, hoặc FlockDB (đó là một trường hợp đặc biệt: một cơ sở dữ liệu đồ thị mà chỉ hỗ trợ các mối quan hệ duy nhất chuyên sâu hoặc danh sách kề, nơi mà bạn không thể đi qua nhiều hơn một mức độ sâu sắc đối với các mối quan hệ ).

Tại sao lựa chọn cơ sở dữ liệu NoSQL

Chúng ta đã đề cập đến rất nhiều trong những vấn đề chung, bạn cần phải nhận thức được để đưa ra quyết định trong thế giới mới của cơ sở dữ liệu NoSQL. Bây giờ là lúc để nói về lý do tại sao chúng ta sẽ chọn cơ sở dữ liệu NoSQL. Dưới đây là một số lý do để xem xét việc sử dụng các cơ sở dữ liệu NoSQL.
  • Để cải thiện năng suất lập trình bằng cách sử dụng một cơ sở dữ liệu phù hợp hơn với nhu cầu của ứng dụng.
  • Để cải thiện hiệu suất truy cập dữ liệu thông qua một số sự kết hợp xử lý khối lượng dữ liệu lớn hơn, giảm độ trễ, và cải thiện thông.
Hầu hết các cơ sở dữ liệu NoSQL là mã nguồn mở, thử nghiệm chúng là một vấn đề đơn giản. Hãy tải về và trải nghiệm. Thậm chí nếu NoSQL không thể được sử dụng như hiện nay, việc thiết kế các hệ thống sử dụng dịch vụ đóng gói hỗ trợ thay đổi công nghệ lưu trữ dữ liệu nhanh như hiện nay như là nhu cầu tất yếu.

Chọn cơ sở dữ liệu NoSQL

Với quá nhiều sự lựa chọn, làm thế nào để chúng ta chọn cơ sở dữ liệu NoSQL? Như đã mô tả sẽ phụ thuộc nhiều vào yêu cầu hệ thống, ngoài ra:
  • Cơ sở dữ liệu key-value nói chung là hữu ích để lưu trữ thông tin phiên làm việc(sessions), hồ sơ người dùng, sở thích, dữ liệu giỏ hàng. Chúng tôi sẽ tránh sử dụng cơ sở dữ liệu key-value khi chúng ta cần phải truy vấn dữ liệu, có các mối quan hệ giữa các dữ liệu được lưu trữ hoặc chúng ta cần để hoạt động trên nhiều phím cùng lúc.
  • Cơ sở dữ liệu tài liệu nói chung là hữu ích cho hệ thống quản lý nội dung như blog, phân tích web, ứng dụng phân tích thời gian thực và thương mại điện tử. Chúng tôi sẽ tránh sử dụng cơ sở dữ liệu tài liệu cho hệ thống mà cần giao dịch phức tạp kéo dài nhiều hoạt động hoặc tổng hợp các truy vấn đối với các cấu trúc khác nhau.
  • Cơ sở dữ liệu column-family thường hữu ích cho hệ thống quản lý nội dung như blog, bảo trì, hết hạn sử dụng, khối lượng ghi nặng như log tập hợp. Chúng ta sẽ tránh sử dụng cơ sở dữ liệu column-family trong hệ thống đang được phát triển sớm hoặc đang thay đổi mẫu truy vấn.
  • Cơ sở dữ liệu đồ thị là phù hợp rất tốt với các không gian vấn đề mà chúng ta đã kết nối dữ liệu, chẳng hạn như các mạng xã hội, dữ liệu không gian, thông tin định tuyến cho hàng hóa và tiền bạc.
Theo https://viblo.asia
Tham khảo: 

Like