2008-10-23 51 views
6

Tôi nên quản lý các bảng tham chiếu đến trang web 'sự kiện' như thế nào. tức là một số hoạt động mà người dùng đã thực hiện trên trang web mà tôi sử dụng để theo dõi. Tôi muốn có thể làm tất cả các loại datamining và tương quan giữa các hoạt động khác nhau của người dùng và những gì họ đã làm.Quản lý cơ sở dữ liệu trang web 'sự kiện'

Hôm nay một mình tôi đã thêm 107.000 hàng vào bảng SiteEvent của tôi. Tôi không nghĩ rằng điều này là bền vững!

Cơ sở dữ liệu là SQL Server. Tôi chủ yếu đề cập đến các hoạt động thực hành tốt nhất liên quan đến việc quản lý một lượng lớn dữ liệu.

Ví dụ:

  • Tôi có nên giữ các bảng trong cơ sở dữ liệu tất cả của riêng mình? Nếu tôi cần phải tham gia với các bảng khác, điều này có thể là một vấn đề. Hiện tại tôi chỉ có một cơ sở dữ liệu với mọi thứ.
  • Tôi nên làm thế nào để thanh lọc các hồ sơ cũ. Tôi muốn đảm bảo tệp db của tôi không tiếp tục phát triển.
  • Các phương pháp hay nhất để sao lưu và cắt bớt nhật ký
  • Sẽ thêm các chỉ mục bổ sung làm tăng đáng kể kích thước của DB với quá nhiều bản ghi?
  • Bất kỳ thứ gì khác tôi cần phải thực hiện trong SQL Server có thể quay trở lại để cắn tôi sau này?

FYI: đó là những bảng

CREATE TABLE [dbo].[SiteEvent](
    [SiteEventId] [int] IDENTITY(1,1) NOT NULL, 
    [SiteEventTypeId] [int] NOT NULL, 
    [SiteVisitId] [int] NOT NULL, 
    [SiteId] [int] NOT NULL, 
    [Date] [datetime] NULL, 
    [Data] [varchar](255) NULL, 
    [Data2] [varchar](255) NULL, 
    [Duration] [int] NULL, 
    [StageSize] [varchar](10) NULL, 

CREATE TABLE [dbo].[SiteVisit](
    [SiteVisitId] [int] IDENTITY(1,1) NOT NULL, 
    [SiteUserId] [int] NULL, 
    [ClientGUID] [uniqueidentifier] ROWGUIDCOL NULL CONSTRAINT [DF_SiteVisit_ClientGUID] DEFAULT (newid()), 
    [ServerGUID] [uniqueidentifier] NULL, 
    [UserGUID] [uniqueidentifier] NULL, 
    [SiteId] [int] NOT NULL, 
    [EntryURL] [varchar](100) NULL, 
    [CampaignId] [varchar](50) NULL, 
    [Date] [datetime] NOT NULL, 
    [Cookie] [varchar](50) NULL, 
    [UserAgent] [varchar](255) NULL, 
    [Platform] [int] NULL, 
    [Referer] [varchar](255) NULL, 
    [RegisteredReferer] [int] NULL, 
    [FlashVersion] [varchar](20) NULL, 
    [SiteURL] [varchar](100) NULL, 
    [Email] [varchar](50) NULL, 
    [FlexSWZVersion] [varchar](20) NULL, 
    [HostAddress] [varchar](20) NULL, 
    [HostName] [varchar](100) NULL, 
    [InitialStageSize] [varchar](20) NULL, 
    [OrderId] [varchar](50) NULL, 
    [ScreenResolution] [varchar](50) NULL, 
    [TotalTimeOnSite] [int] NULL, 
    [CumulativeVisitCount] [int] NULL CONSTRAINT [DF_SiteVisit_CumulativeVisitCount] DEFAULT ((0)), 
    [ContentActivatedTime] [int] NULL CONSTRAINT [DF_SiteVisit_ContentActivatedTime] DEFAULT ((0)), 
    [ContentCompleteTime] [int] NULL, 
    [MasterVersion] [int] NULL CONSTRAINT [DF_SiteVisit_MasterVersion] DEFAULT ((0)), 

Trả lời

0

lại suy nghĩ vấn đề có thể chỉ là những gì bác sĩ đã ra lệnh. Có thể 100k hồ sơ mỗi ngày thực sự hữu ích? Có vẻ như quá tải thông tin với tôi. Có thể bắt đầu bằng cách giảm mức độ chi tiết của theo dõi sử dụng của bạn?

+0

có! tôi chắc chắn muốn làm điều đó! đây chỉ là khoảng 9 sự kiện cho mỗi khách truy cập mặc dù vậy nó không hoàn toàn overkill. cộng với chúng tôi mong đợi lưu lượng truy cập nhiều hơn đến – Simon

0

Về mặt suy nghĩ lại vấn đề, bạn có thể khám phá một trong nhiều gói thống kê web trên mạng. Chỉ có một vài trường trong bảng mẫu của bạn không phải là một phần của việc triển khai ngoài mạng của WebTrends hoặc Google Analytics hoặc nhiều mục khác. Các mục khác trong bảng của bạn cũng có thể được thiết lập, nhưng hãy suy nghĩ nhiều hơn một chút và một số nghiên cứu về gói nào sẽ đáp ứng tất cả nhu cầu của bạn. Hầu hết các công cụ trên kệ đều có thể xử lý theo dõi chiến dịch, v.v ... những ngày này.

Một tùy chọn khác sẽ là giảm tải công cụ phổ biến thành gói thống kê web chuẩn và sau đó phân tích cú pháp này trở lại SQL Server bằng dữ liệu tùy chỉnh ngoài băng thông của bạn.

Tôi không biết bạn có bao nhiêu dữ liệu khác, nhưng nếu ghi 107K + một ngày đại diện cho số lượng lớn, bạn có thể sẽ dành thời gian xử lý số liệu thống kê web của bạn.

+0

lý do chính chúng tôi không sử dụng một số theo dõi ngoài hộp là trang web dựa trên Flash/Flex. tôi cũng muốn cụ thể để có thể tham gia với các bảng cụ thể khác của miền. nó làm ok nhưng tôi chỉ muốn bắt đầu nghe lời khuyên! cảm ơn – Simon

0

Tôi sẽ giữ chúng trong cùng một cơ sở dữ liệu, trừ khi bạn có thể an toàn thanh lọc/lưu trữ hồ sơ cũ để truy vấn OLAP và sau đó giữ cơ sở dữ liệu chính cho mục đích OLTP.

Đảm bảo bạn đặt kích thước ban đầu lớn cho cơ sở dữ liệu và đặt giá trị autogrow lớn và đảm bảo bạn không hết dung lượng đĩa. Bản ghi 107k một ngày sẽ chiếm không gian bất kể bạn cất giữ nó như thế nào.

Đối với các bản sao lưu, điều đó hoàn toàn phụ thuộc vào yêu cầu của bạn.Một hàng tuần đầy đủ, khác biệt hàng ngày và một/hai giờ khác nhau nên làm việc tốt miễn là hệ thống con IO có thể đối phó với nó.

Chỉ mục bổ sung sẽ chiếm dung lượng, nhưng một lần nữa, chỉ mục phụ thuộc vào cột bạn thêm. Nếu bạn có 10^6 hàng và bạn thêm một chỉ số nonclustered nó sẽ mất 10^6 * 4 * 2. Đó là 10^6 cho cột được lập chỉ mục thực tế và thêm 4 byte cho khóa chính, cho mỗi mục chỉ mục. Vì vậy, đối với mỗi 1 triệu bản ghi, một chỉ mục không được quản lý trên một cột int sẽ chiếm khoảng 8MB.

Khi bảng phát triển, bạn có thể thêm máy chủ và thực hiện phân vùng ngang trên bảng để bạn trải đều dữ liệu trên nhiều máy chủ. Đối với IO, có thể sẽ là rào cản lớn nhất, hãy đảm bảo bạn có đủ cọc để xử lý tải, tốt nhất là với các chỉ mục nằm trên đĩa/LUN của riêng chúng và dữ liệu thực tế trên bộ đĩa riêng của chúng./LUN.

1

Cá nhân tôi sẽ giữ hoàn toàn giữ hồ sơ nhật ký bên ngoài cơ sở dữ liệu chính. Hiệu suất của ứng dụng của bạn sẽ mất một hit lớn bằng việc phải liên tục viết.

Tôi nghĩ cách đi là tạo cơ sở dữ liệu thứ cấp trên một máy khác, xuất bản api SOAP không liên quan đến lược đồ DB cơ bản và báo cáo ứng dụng đó. Tôi cũng đề nghị rằng các ngữ nghĩa có thể viết (không chờ phản hồi xác nhận) có thể làm cho bạn, nếu bạn có thể mạo hiểm mất một số thông tin này.

Trên DB phụ, bạn có thể có các cuộc gọi API kích hoạt một số loại cắt xén cơ sở dữ liệu hoặc tách/sao lưu/tạo lại quy trình bảo trì. Nếu bạn cần một bản ghi thì bạn không nên từ bỏ khả năng nó có ích trong tương lai.

Nếu bạn cần một số loại dịch vụ phân tích về điều đó, cách tốt nhất để đi là SQL Server. Nếu không thì MySQL hoặc PostGREs sẽ thực hiện công việc rẻ hơn nhiều.

2

Bạn đã nói hai điều xung đột với nhau.

  1. Tôi muốn có thể thực hiện tất cả các loại datamining và tương quan giữa các hoạt động khác nhau của người dùng và những gì họ đã làm.
  2. Tôi muốn đảm bảo tệp db của tôi không tiếp tục phát triển.

Tôi cũng là một người hâm mộ lớn về khai thác dữ liệu, nhưng bạn cần dữ liệu để khai thác. Trong tâm trí của tôi, tạo ra một thiết kế cơ sở dữ liệu mở rộng và kế hoạch cho nó phát triển TREMENDOUSLY. Sau đó, lấy tất cả dữ liệu bạn có thể. Sau đó, cuối cùng, bạn sẽ có thể làm tất cả các khai thác dữ liệu mát mẻ mà bạn đang mơ ước.

Các vấn đề liên quan