推荐-全文搜索引擎的设计与实现 精品

江汉大学毕业论文（设计）外文翻译原文来源The Hadoop Distributed File System: Architecture and Design 中文译文Hadoop分布式文件系统：架构和设计姓名 XXXX学号 XXXX2013年4月8 日英文原文The Hadoop Distributed File System: Architecture and DesignSource：/docs/r0.18.3/hdfs_design.html IntroductionThe Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant. HDFS is highly fault-tolerant and is designed to be deployed onlow-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. HDFS relaxes a few POSIX requirements to enable streaming access to file system data. HDFS was originally built as infrastructure for the Apache Nutch web search engine project. HDFS is part of the Apache Hadoop Core project. The project URL is/core/.Assumptions and GoalsHardware FailureHardware failure is the norm rather than the exception. An HDFS instance may consist of hundreds or thousands of server machines, each storing part of the file system’s data. The fact that there are a huge number of components and that each component has a non-trivial probability of failure means that some component of HDFS is always non-functional. Therefore, detection of faults and quick, automatic recovery from them is a core architectural goal of HDFS.Streaming Data AccessApplications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users. The emphasis is on high throughput of data access rather than low latency of data access. POSIX imposes many hard requirements that are notneeded for applications that are targeted for HDFS. POSIX semantics in a few key areas has been traded to increase data throughput rates.Large Data SetsApplications that run on HDFS have large data sets. A typical file in HDFS is gigabytes to terabytes in size. Thus, HDFS is tuned to support large files. It should provide high aggregate data bandwidth and scale to hundreds of nodes in a single cluster. It should support tens of millions of files in a single instance.Simple Coherency ModelHDFS applications need a write-once-read-many access model for files. A file once created, written, and closed need not be changed. This assumption simplifies data coherency issues and enables high throughput data access. AMap/Reduce application or a web crawler application fits perfectly with this model. There is a plan to support appending-writes to files in the future.“Moving Computation is Cheaper than Moving Data”A computation requested by an application is much more efficient if it is executed near the data it operates on. This is especially true when the size of the data set is huge. This minimizes network congestion and increases the overall throughput of the system. The assumption is that it is often better to migrate the computation closer to where the data is located rather than moving the data to where the application is running. HDFS provides interfaces for applications to move themselves closer to where the data is located.Portability Across Heterogeneous Hardware and Software PlatformsHDFS has been designed to be easily portable from one platform to another. This facilitates widespread adoption of HDFS as a platform of choice for a large set of applications.NameNode and DataNodesHDFS has a master/slave architecture. An HDFS cluster consists of a single NameNode, a master server that manages the file system namespace and regulates access to files by clients. In addition, there are a number of DataNodes, usually one per node in the cluster, which manage storage attached to the nodes that they run on. HDFS exposes a file system namespace and allows user data to be stored in files. Internally, a file is split into one or more blocks and these blocksare stored in a set of DataNodes. The NameNode executes file system namespace operations like opening, closing, and renaming files and directories. It also determines the mapping of blocks to DataNodes. The DataNodes are responsible for serving read and write requests from the file system’s clients. The DataNodes also perform block creation, deletion, and replication upon instruction from the NameNode.The NameNode and DataNode are pieces of software designed to run on commodity machines. These machines typically run a GNU/Linux operating system (OS). HDFS is built using the Java language; any machine that supports Java can run the NameNode or the DataNode software. Usage of the highly portable Java language means that HDFS can be deployed on a wide range ofmachines. A typical deployment has a dedicated machine that runs only the NameNode software. Each of the other machines in the cluster runs one instance of the DataNode software. The architecture does not preclude running multiple DataNodes on the same machine but in a real deployment that is rarely the case.The existence of a single NameNode in a cluster greatly simplifies the architecture of the system. The NameNode is the arbitrator and repository for all HDFS metadata. The system is designed in such a way that user data never flows through the NameNode.The File System NamespaceHDFS supports a traditional hierarchical file organization. A user or an application can create directories and store files inside these directories. The file system namespace hierarchy is similar to most other existing file systems; one can create and remove files, move a file from one directory to another, or rename a file. HDFS does not yet implement user quotas or access permissions. HDFS does not support hard links or soft links. However, the HDFS architecture does not preclude implementing these features.The NameNode maintains the file system namespace. Any change to the file system namespace or its properties is recorded by the NameNode. An application can specify the number of replicas of a file that should be maintained by HDFS. The number of copies of a file is called the replication factor of that file. This information is stored by the NameNode.Data ReplicationHDFS is designed to reliably store very large files across machines in a large cluster. It stores each file as a sequence of blocks; all blocks in a file except the last block are the same size. The blocks of a file are replicated for fault tolerance. The block size and replication factor are configurable per file. An application can specify the number of replicas of a file. The replication factor can be specified at file creation time and can be changed later. Files in HDFS are write-once and have strictly one writer at any time.The NameNode makes all decisions regarding replication of blocks. It periodically receives a Heartbeat and a Blockreport from each of the DataNodes in the cluster.Receipt of a Heartbeat implies that the DataNode is functioning properly. A Blockreport contains a list of all blocks on a DataNode.Replica Placement: The First Baby StepsThe placement of replicas is critical to HDFS reliability and performance. Optimizing replica placement distinguishes HDFS from most other distributed file systems. This is a feature that needs lots of tuning and experience. The purpose of a rack-aware replica placement policy is to improve data reliability, availability, and network bandwidth utilization. The current implementation for the replica placement policy is a first effort in this direction. The short-term goals of implementing this policy are to validate it on production systems, learn more about its behavior, and build a foundation to test and research more sophisticated policies.Large HDFS instances run on a cluster of computers that commonly spread across many racks. Communication between two nodes in different racks has to go through switches. In most cases, network bandwidth between machines in the same rack is greater than network bandwidth between machines in different racks.The NameNode determines the rack id each DataNode belongs to via the process outlined in Rack Awareness. A simple but non-optimal policy is to place replicas on unique racks. This prevents losing data when an entire rack fails and allows use of bandwidth from multiple racks when reading data. This policy evenly distributes replicas in the cluster which makes it easy to balance load on component failure. However, this policy increases the cost of writes because a write needs to transfer blocks to multiple racks.For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on one node in the local rack, another on a different node in the local rack, and the last on a different node in a different rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.The current, default replica placement policy described here is a work in progress. Replica SelectionTo minimize global bandwidth consumption and read latency, HDFS tries to satisfy a read request from a replica that is closest to the reader. If there exists a replica on the same rack as the reader node, then that replica is preferred to satisfy the read request. If angg/ HDFS cluster spans multiple data centers, then a replica that is resident in the local data center is preferred over any remote replica.SafemodeOn startup, the NameNode enters a special state called Safemode. Replication of data blocks does not occur when the NameNode is in the Safemode state. The NameNode receives Heartbeat and Blockreport messages from the DataNodes. A Blockreport contains the list of data blocks that a DataNode is hosting. Each block has a specified minimum number of replicas. A block is considered safely replicated when the minimum number of replicas of that data block has checked in with the NameNode. After a configurable percentage of safely replicated data blocks checks in with the NameNode (plus an additional 30 seconds), the NameNode exits the Safemode state. It then determines the list of data blocks (if any) that still have fewer than the specified number of replicas. The NameNode then replicates these blocks to other DataNodes.The Persistence of File System MetadataThe HDFS namespace is stored by the NameNode. The NameNode uses a transaction log called the EditLog to persistently record every change that occurs to file system metadata. For example, creating a new file in HDFS causes the NameNode to insert a record into the EditLog indicating this. Similarly, changing the replication factor of a file causes a new record to be inserted into the EditLog. The NameNode uses a file in its local host OS file system to store the EditLog. The entire file system namespace, including the mapping of blocks to files and file system properties, is stored in a file called the FsImage. The FsImage is stored as a file in the NameNode’s local file system too.The NameNode keeps an image of the entire file system namespace and file Blockmap in memory. This key metadata item is designed to be compact, such that a NameNode with 4 GB of RAM is plenty to support a huge number of files and directories. When the NameNode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the in-memory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint. In the current implementation, a checkpoint only occurs when the NameNode starts up. Work is in progress to support periodic checkpointing in the near future.The DataNode stores HDFS data in files in its local file system. The DataNode has no knowledge about HDFS files. It stores each block of HDFS data in a separatefile in its local file system. The DataNode does not create all files in the same directory. Instead, it uses a heuristic to determine the optimal number of files per directory and creates subdirectories appropriately. It is not optimal to create all local files in the same directory because the local file system might not be able to efficiently support a huge number of files in a single directory. When a DataNode starts up, it scans through its local file system, generates a list of all HDFS data blocks that correspond to each of these local files and sends this report to the NameNode: this is the Blockreport.The Communication ProtocolsAll HDFS communication protocols are layered on top of the TCP/IP protocol. A client establishes a connection to a configurable TCP port on the NameNode machine. It talks the ClientProtocol with the NameNode. The DataNodes talk to the NameNode using the DataNode Protocol. A Remote Procedure Call (RPC) abstraction wraps both the Client Protocol and the DataNode Protocol. By design, the NameNode never initiates any RPCs. Instead, it only responds to RPC requests issued by DataNodes or clients.RobustnessThe primary objective of HDFS is to store data reliably even in the presence of failures. The three common types of failures are NameNode failures, DataNode failures and network partitions.Data Disk Failure, Heartbeats and Re-ReplicationEach DataNode sends a Heartbeat message to the NameNode periodically. A network partition can cause a subset of DataNodes to lose connectivity with the NameNode. The NameNode detects this condition by the absence of a Heartbeat message. The NameNode marks DataNodes without recent Heartbeats as dead and does not forward any new IO requests to them. Any data that was registered to a dead DataNode is not available to HDFS any more. DataNode death may cause the replication factor of some blocks to fall below their specified value. The NameNode constantly tracks which blocks need to be replicated and initiates replication whenever necessary. The necessity for re-replication may arise due to many reasons: a DataNode may become unavailable, a replica may become corrupted, a hard disk on a DataNode may fail, or the replication factor of a file may be increased.Cluster RebalancingThe HDFS architecture is compatible with data rebalancing schemes. A scheme might automatically move data from one DataNode to another if the free space on a DataNode falls below a certain threshold. In the event of a sudden high demand for a particular file, a scheme might dynamically create additional replicas and rebalance other data in the cluster. These types of data rebalancing schemes are not yet implemented.Data IntegrityIt is possible that a block of data fetched from a DataNode arrives corrupted. This corruption can occur because of faults in a storage device, network faults, or buggy software. The HDFS client software implements checksum checking on the contents of HDFS files. When a client creates an HDFS file, it computes a checksum of each block of the file and stores these checksums in a separate hidden file in the same HDFS namespace. When a client retrieves file contents it verifies that the data it received from each DataNode matches the checksum stored in the associated checksum file. If not, then the client can opt to retrieve that block from another DataNode that has a replica of that block.Metadata Disk FailureThe FsImage and the EditLog are central data structures of HDFS. A corruption of these files can cause the HDFS instance to be non-functional. For this reason, the NameNode can be configured to support maintaining multiple copies of the FsImage and EditLog. Any update to either the FsImage or EditLog causes each of the FsImages and EditLogs to get updated synchronously. This synchronous updating of multiple copies of the FsImage and EditLog may degrade the rate of namespace transactions per second that a NameNode can support. However, this degradation is acceptable because even though HDFS applications are very data intensive in nature, they are not metadata intensive. When a NameNode restarts, it selects the latest consistent FsImage and EditLog to use.The NameNode machine is a single point of failure for an HDFS cluster. If the NameNode machine fails, manual intervention is necessary. Currently, automatic restart and failover of the NameNode software to another machine is not supported.Snapshots。

江汉大学毕业论文（设计）外文翻译原文来源The Hadoop Distributed File System: Architecture and Design 中文译文Hadoop分布式文件系统：架构和设计姓名 XXXX学号 2007082021372013年4月8 日英文原文The Hadoop Distributed File System: Architecture and DesignSource：/docs/r0.18.3/hdfs_design.html IntroductionThe Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant. HDFS is highly fault-tolerant and is designed to be deployed onlow-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. HDFS relaxes a few POSIX requirements to enable streaming access to file system data. HDFS was originally built as infrastructure for the Apache Nutch web search engine project. HDFS is part of the Apache Hadoop Core project. The project URL is/core/.Assumptions and GoalsHardware FailureHardware failure is the norm rather than the exception. An HDFS instance may consist of hundreds or thousands of server machines, each storing part of the file system’s data. The fact that there are a huge number of components and that each component has a non-trivial probability of failure means that some component of HDFS is always non-functional. Therefore, detection of faults and quick, automatic recovery from them is a core architectural goal of HDFS.Streaming Data AccessApplications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users. The emphasis is on high throughput of data access rather than low latency of data access. POSIX imposes many hard requirements that are notneeded for applications that are targeted for HDFS. POSIX semantics in a few key areas has been traded to increase data throughput rates.Large Data SetsApplications that run on HDFS have large data sets. A typical file in HDFS is gigabytes to terabytes in size. Thus, HDFS is tuned to support large files. It should provide high aggregate data bandwidth and scale to hundreds of nodes in a single cluster. It should support tens of millions of files in a single instance.Simple Coherency ModelHDFS applications need a write-once-read-many access model for files. A file once created, written, and closed need not be changed. This assumption simplifies data coherency issues and enables high throughput data access. AMap/Reduce application or a web crawler application fits perfectly with this model. There is a plan to support appending-writes to files in the future.“Moving Computation is Cheaper than Moving Data”A computation requested by an application is much more efficient if it is executed near the data it operates on. This is especially true when the size of the data set is huge. This minimizes network congestion and increases the overall throughput of the system. The assumption is that it is often better to migrate the computation closer to where the data is located rather than moving the data to where the application is running. HDFS provides interfaces for applications to move themselves closer to where the data is located.Portability Across Heterogeneous Hardware and Software PlatformsHDFS has been designed to be easily portable from one platform to another. This facilitates widespread adoption of HDFS as a platform of choice for a large set of applications.NameNode and DataNodesHDFS has a master/slave architecture. An HDFS cluster consists of a single NameNode, a master server that manages the file system namespace and regulates access to files by clients. In addition, there are a number of DataNodes, usually one per node in the cluster, which manage storage attached to the nodes that they run on. HDFS exposes a file system namespace and allows user data to be stored in files. Internally, a file is split into one or more blocks and these blocksare stored in a set of DataNodes. The NameNode executes file system namespace operations like opening, closing, and renaming files and directories. It also determines the mapping of blocks to DataNodes. The DataNodes are responsible for serving read and write requests from the file system’s clients. The DataNodes also perform block creation, deletion, and replication upon instruction from the NameNode.The NameNode and DataNode are pieces of software designed to run on commodity machines. These machines typically run a GNU/Linux operating system (OS). HDFS is built using the Java language; any machine that supports Java can run the NameNode or the DataNode software. Usage of the highly portable Java language means that HDFS can be deployed on a wide range ofmachines. A typical deployment has a dedicated machine that runs only the NameNode software. Each of the other machines in the cluster runs one instance of the DataNode software. The architecture does not preclude running multiple DataNodes on the same machine but in a real deployment that is rarely the case.The existence of a single NameNode in a cluster greatly simplifies the architecture of the system. The NameNode is the arbitrator and repository for all HDFS metadata. The system is designed in such a way that user data never flows through the NameNode.The File System NamespaceHDFS supports a traditional hierarchical file organization. A user or an application can create directories and store files inside these directories. The file system namespace hierarchy is similar to most other existing file systems; one can create and remove files, move a file from one directory to another, or rename a file. HDFS does not yet implement user quotas or access permissions. HDFS does not support hard links or soft links. However, the HDFS architecture does not preclude implementing these features.The NameNode maintains the file system namespace. Any change to the file system namespace or its properties is recorded by the NameNode. An application can specify the number of replicas of a file that should be maintained by HDFS. The number of copies of a file is called the replication factor of that file. This information is stored by the NameNode.Data ReplicationHDFS is designed to reliably store very large files across machines in a large cluster. It stores each file as a sequence of blocks; all blocks in a file except the last block are the same size. The blocks of a file are replicated for fault tolerance. The block size and replication factor are configurable per file. An application can specify the number of replicas of a file. The replication factor can be specified at file creation time and can be changed later. Files in HDFS are write-once and have strictly one writer at any time.The NameNode makes all decisions regarding replication of blocks. It periodically receives a Heartbeat and a Blockreport from each of the DataNodes in the cluster.Receipt of a Heartbeat implies that the DataNode is functioning properly. A Blockreport contains a list of all blocks on a DataNode.Replica Placement: The First Baby StepsThe placement of replicas is critical to HDFS reliability and performance. Optimizing replica placement distinguishes HDFS from most other distributed file systems. This is a feature that needs lots of tuning and experience. The purpose of a rack-aware replica placement policy is to improve data reliability, availability, and network bandwidth utilization. The current implementation for the replica placement policy is a first effort in this direction. The short-term goals of implementing this policy are to validate it on production systems, learn more about its behavior, and build a foundation to test and research more sophisticated policies.Large HDFS instances run on a cluster of computers that commonly spread across many racks. Communication between two nodes in different racks has to go through switches. In most cases, network bandwidth between machines in the same rack is greater than network bandwidth between machines in different racks.The NameNode determines the rack id each DataNode belongs to via the process outlined in Rack Awareness. A simple but non-optimal policy is to place replicas on unique racks. This prevents losing data when an entire rack fails and allows use of bandwidth from multiple racks when reading data. This policy evenly distributes replicas in the cluster which makes it easy to balance load on component failure. However, this policy increases the cost of writes because a write needs to transfer blocks to multiple racks.For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on one node in the local rack, another on a different node in the local rack, and the last on a different node in a different rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.The current, default replica placement policy described here is a work in progress. Replica SelectionTo minimize global bandwidth consumption and read latency, HDFS tries to satisfy a read request from a replica that is closest to the reader. If there exists a replica on the same rack as the reader node, then that replica is preferred to satisfy the read request. If angg/ HDFS cluster spans multiple data centers, then a replica that is resident in the local data center is preferred over any remote replica.SafemodeOn startup, the NameNode enters a special state called Safemode. Replication of data blocks does not occur when the NameNode is in the Safemode state. The NameNode receives Heartbeat and Blockreport messages from the DataNodes. A Blockreport contains the list of data blocks that a DataNode is hosting. Each block has a specified minimum number of replicas. A block is considered safely replicated when the minimum number of replicas of that data block has checked in with the NameNode. After a configurable percentage of safely replicated data blocks checks in with the NameNode (plus an additional 30 seconds), the NameNode exits the Safemode state. It then determines the list of data blocks (if any) that still have fewer than the specified number of replicas. The NameNode then replicates these blocks to other DataNodes.The Persistence of File System MetadataThe HDFS namespace is stored by the NameNode. The NameNode uses a transaction log called the EditLog to persistently record every change that occurs to file system metadata. For example, creating a new file in HDFS causes the NameNode to insert a record into the EditLog indicating this. Similarly, changing the replication factor of a file causes a new record to be inserted into the EditLog. The NameNode uses a file in its local host OS file system to store the EditLog. The entire file system namespace, including the mapping of blocks to files and file system properties, is stored in a file called the FsImage. The FsImage is stored as a file in the NameNode’s local file system too.The NameNode keeps an image of the entire file system namespace and file Blockmap in memory. This key metadata item is designed to be compact, such that a NameNode with 4 GB of RAM is plenty to support a huge number of files and directories. When the NameNode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the in-memory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint. In the current implementation, a checkpoint only occurs when the NameNode starts up. Work is in progress to support periodic checkpointing in the near future.The DataNode stores HDFS data in files in its local file system. The DataNode has no knowledge about HDFS files. It stores each block of HDFS data in a separatefile in its local file system. The DataNode does not create all files in the same directory. Instead, it uses a heuristic to determine the optimal number of files per directory and creates subdirectories appropriately. It is not optimal to create all local files in the same directory because the local file system might not be able to efficiently support a huge number of files in a single directory. When a DataNode starts up, it scans through its local file system, generates a list of all HDFS data blocks that correspond to each of these local files and sends this report to the NameNode: this is the Blockreport.The Communication ProtocolsAll HDFS communication protocols are layered on top of the TCP/IP protocol. A client establishes a connection to a configurable TCP port on the NameNode machine. It talks the ClientProtocol with the NameNode. The DataNodes talk to the NameNode using the DataNode Protocol. A Remote Procedure Call (RPC) abstraction wraps both the Client Protocol and the DataNode Protocol. By design, the NameNode never initiates any RPCs. Instead, it only responds to RPC requests issued by DataNodes or clients.RobustnessThe primary objective of HDFS is to store data reliably even in the presence of failures. The three common types of failures are NameNode failures, DataNode failures and network partitions.Data Disk Failure, Heartbeats and Re-ReplicationEach DataNode sends a Heartbeat message to the NameNode periodically. A network partition can cause a subset of DataNodes to lose connectivity with the NameNode. The NameNode detects this condition by the absence of a Heartbeat message. The NameNode marks DataNodes without recent Heartbeats as dead and does not forward any new IO requests to them. Any data that was registered to a dead DataNode is not available to HDFS any more. DataNode death may cause the replication factor of some blocks to fall below their specified value. The NameNode constantly tracks which blocks need to be replicated and initiates replication whenever necessary. The necessity for re-replication may arise due to many reasons: a DataNode may become unavailable, a replica may become corrupted, a hard disk on a DataNode may fail, or the replication factor of a file may be increased.Cluster RebalancingThe HDFS architecture is compatible with data rebalancing schemes. A scheme might automatically move data from one DataNode to another if the free space on a DataNode falls below a certain threshold. In the event of a sudden high demand for a particular file, a scheme might dynamically create additional replicas and rebalance other data in the cluster. These types of data rebalancing schemes are not yet implemented.Data IntegrityIt is possible that a block of data fetched from a DataNode arrives corrupted. This corruption can occur because of faults in a storage device, network faults, or buggy software. The HDFS client software implements checksum checking on the contents of HDFS files. When a client creates an HDFS file, it computes a checksum of each block of the file and stores these checksums in a separate hidden file in the same HDFS namespace. When a client retrieves file contents it verifies that the data it received from each DataNode matches the checksum stored in the associated checksum file. If not, then the client can opt to retrieve that block from another DataNode that has a replica of that block.Metadata Disk FailureThe FsImage and the EditLog are central data structures of HDFS. A corruption of these files can cause the HDFS instance to be non-functional. For this reason, the NameNode can be configured to support maintaining multiple copies of the FsImage and EditLog. Any update to either the FsImage or EditLog causes each of the FsImages and EditLogs to get updated synchronously. This synchronous updating of multiple copies of the FsImage and EditLog may degrade the rate of namespace transactions per second that a NameNode can support. However, this degradation is acceptable because even though HDFS applications are very data intensive in nature, they are not metadata intensive. When a NameNode restarts, it selects the latest consistent FsImage and EditLog to use.The NameNode machine is a single point of failure for an HDFS cluster. If the NameNode machine fails, manual intervention is necessary. Currently, automatic restart and failover of the NameNode software to another machine is not supported.SnapshotsSnapshots support storing a copy of data at a particular instant of time. One usage of the snapshot feature may be to roll back a corrupted HDFS instance to a previously known good point in time. HDFS does not currently support snapshots but will in a future release.Data OrganizationData BlocksHDFS is designed to support very large files. Applications that are compatible with HDFS are those that deal with large data sets. These applications write their data only once but they read it one or more times and require these reads to be satisfied at streaming speeds. HDFS supports write-once-read-many semantics on files. A typical block size used by HDFS is 64 MB. Thus, an HDFS file is chopped up into 64 MB chunks, and if possible, each chunk will reside on a different DataNode.StagingA client request to create a file does not reach the NameNode immediately. In fact, initially the HDFS client caches the file data into a temporary local file. Application writes are transparently redirected to this temporary local file. When the local file accumulates data worth over one HDFS block size, the client contacts the NameNode. The NameNode inserts the file name into the file system hierarchy and allocates a data block for it. The NameNode responds to the client request with the identity of the DataNode and the destination data block. Then the client flushes the block of data from the local temporary file to the specified DataNode. When a file is closed, the remaining un-flushed data in the temporary local file is transferred to the DataNode. The client then tells the NameNode that the file is closed. At this point, the NameNode commits the file creation operation into a persistent store. If the NameNode dies before the file is closed, the file is lost.The above approach has been adopted after careful consideration of target applications that run on HDFS. These applications need streaming writes to files. If a client writes to a remote file directly without any client side buffering, the network speed and the congestion in the network impacts throughput considerably. This approach is not without precedent. Earlier distributed file systems, e.g. AFS, have used client side caching to improve performance. APOSIX requirement has been relaxed to achieve higher performance of data uploads.Replication PipeliningWhen a client is writing data to an HDFS file, its data is first written to a local file as explained in the previous section. Suppose the HDFS file has a replication factor of three. When the local file accumulates a full block of user data, the client retrieves a list of DataNodes from the NameNode. This list contains the DataNodes that will host a replica of that block. The client then flushes the data block to the first DataNode. The first DataNode starts receiving the data in small portions (4 KB), writes each portion to its local repository and transfers that portion to the second DataNode in the list. The second DataNode, in turn starts receiving each portion of the data block, writes that portion to its repository and then flushes that portion to the third DataNode. Finally, the third DataNode writes the data to its local repository. Thus, a DataNode can be receiving data from the previous one in the pipeline and at the same time forwarding data to the next one in the pipeline. Thus, the data is pipelined from one DataNode to the next.AccessibilityHDFS can be accessed from applications in many different ways. Natively, HDFS provides a Java API for applications to use. A C language wrapper for this Java API is also available. In addition, an HTTP browser can also be used to browse the files of an HDFS instance. Work is in progress to expose HDFS through the WebDAV protocol.FS ShellHDFS allows user data to be organized in the form of files and directories. It provides a commandline interface called FS shell that lets a user interact with the data in HDFS. The syntax of this command set is similar to other shells (e.g. bash, csh) that users are already familiar with. Here are some sample action/command pairs:FS shell is targeted for applications that need a scripting language to interact with the stored data.DFSAdminThe DFSAdmin command set is used for administering an HDFS cluster. These are commands that are used only by an HDFS administrator. Here are some sample action/command pairs:Browser InterfaceA typical HDFS install configures a web server to expose the HDFS namespace through a configurable TCP port. This allows a user to navigate the HDFS namespace and view the contents of its files using a web browser.Space ReclamationFile Deletes and UndeletesWhen a file is deleted by a user or an application, it is not immediately removed from HDFS. Instead, HDFS first renames it to a file in the /trash directory. The file can be restored quickly as long as it remains in /trash. A file remains in/trash for a configurable amount of time. After the expiry of its life in /trash, the NameNode deletes the file from the HDFS namespace. The deletion of a file causes the blocks associated with the file to be freed. Note that there could be an appreciable time delay between the time a file is deleted by a user and the time of the corresponding increase in free space in HDFS.A user can Undelete a file after deleting it as long as it remains in the /trash directory. If a user wants to undelete a file that he/she has deleted, he/she can navigate the /trash directory and retrieve the file. The /trash directory contains only the latest copy of the file that was deleted. The /trash directory is just like any other directory with one special feature: HDFS applies specified policies to automatically delete files from this directory. The current default policy is to delete files from /trash that are more than 6 hours old. In the future, this policy will be configurable through a well defined interface.Decrease Replication FactorWhen the replication factor of a file is reduced, the NameNode selects excess replicas that can be deleted. The next Heartbeat transfers this information to the DataNode. The DataNode then removes the corresponding blocks and the corresponding free space appears in the cluster. Once again, there might be a time delay between the completion of the setReplication API call and the appearance of free space in the cluster.中文译本原文地址:/docs/r0.18.3/hdfs_design.html一、引言Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。

江汉大学毕业论文（设计）文献综述综述名称全文搜索引擎的设计与实现姓名cccc学号2007082021372013年4月8日一、绪论目前定制和维护搜索引擎的需求越来越大，对于处理庞大的网络数据，如何有效的去存储它并访问到我们需要的信息，变得尤为重要。

Web搜索引擎能有很好的帮助我们解决这一问题。

本文阐述了一个全文搜索引擎的原理及其设计和实现过程。

该系统采用B/S 模式的Java Web平台架构实现，采用Nutch相关框架，包括Nutch，Solr，Hadoop,以及Nutch的基础框架Lucene对全网信息的采集和检索。

文中阐述了Nutch相关框架的背景，基础原理和应用。

Nutch相关框架的出现，使得在java平台上构建个性化搜索引擎成为一件简单又可靠的事情。

Nutch 致力于让每个人能很容易, 同时花费很少就可以配置世界一流的Web搜索引擎。

目前国内有很多大公司，比如百度、雅虎，都在使用Nutch相关框架。

由于Nutch是开源的，阅读其源代码，可以让我们对搜索引擎实现有更加深刻的感受，并且能够更加深度的定制需要的搜索引擎实现细节。

本文首先介绍了课题研究背景，然后对系统涉及到的理论知识，框架的相关理论做了详细说明，最后按照软件工程的开发方法逐步实现系统功能。

二、文献研究2.1 Nutch技术Nutch 是一个开源Java 实现的搜索引擎。

它提供了我们运行的搜索引擎所需的全部工具。

包括全文搜索和Web爬虫。

尽管Web搜索是漫游Internet的基本要求, 但是现有web搜索引擎的数目却在下降。

并且这很有可能进一步演变成为一个公司垄断了几乎所有的web搜索为其谋取商业利益.这显然不利于广大Internet用户。

Nutch为我们提供了这样一个不同的选择. 相对于那些商用的搜索引擎, Nutch作为开放源代码搜索引擎将会更加透明, 从而更值得大家信赖. 现在所有主要的搜索引擎都采用私有的排序算法, 而不会解释为什么一个网页会排在一个特定的位置。

江汉大学毕业论文（设计）开题报告注：1、本页作为毕业论文（设计）开题报告的封面，请将开题报告正文装订于后。

2、开题报告内容主要包括：课题来源；任务要求的理解；国内外研究现状和发展趋势、学术动态；本任务研究的内容、主要论点；设计方案及比较，设计实现的途径及技术路线；最终的目标、能否完成及完成时间；现有条件及尚需增加的措施、设备、资料。

请各专业根据实际情况确定开题报告的内容及要求。

第一章课题背景随着互联网的快速发展，越来越丰富的信息呈现在用户面前，但同时伴随的问题是用户越来越难以获得其最需要的信息。

为了解决此问题，出现了网络搜索引擎。

网络搜索引擎中以基于WWW 的搜索引擎应用范围最为广泛。

网络搜索引擎是指对WWW站点资源和其它资源进行索引和检索的一类检索机制。

全文搜索引擎是目前最为普及的应用，通过从互联网上提取各个网站的信息(以网页文字为主)建立数据库，用户查询的时候便在数据库中检索与用户查询条件相匹配的记录，最终将匹配的那些记录，按一定的排列顺序显示给用户。

国外具代表性的全文检索搜索引擎有Google、Yahoo、Bing等，国内著名的有百度、中搜等。

第二章课题研究目的针对搜索引擎广阔的应用前景以及分析国内外搜索引擎的发展现状，根据搜索引擎系统的工作原理设计一种基于Internet的全文搜索引擎模型，它从互联网上获取网页，建立索引数据库，并采用数据库管理作业和多线程技术以提高全文搜索的性能和效率，从技术上可以适用于任何有全文搜索需求的应用。

第三章可行性研究3.1 经济可行性分析该搜索引擎的实现，全部采用开源框架，可以从互联网上直接下载。

使用设备上只需要一台PC机。

3.2 技术可行性分析该搜索引擎总体上使用通用的Java Web架构，使用Nutch构建一个网络爬虫，作为程序的搜索器。

使用Solr对程序建立索引。

使用JSP作为前台展示页面。

这类资料在网络上比较容易获取，学习成本较低廉。

第四章主要研究和设计内容4.1课题主要研究内容一般来说搜索引擎都由：用户接口，搜索器，索引生成器和查询处理器4个部分组成。

目录摘要 (1)ABSTRACT (2)第1章绪论 (3)1.1 课题的研究背景与意义 (3)1.2 研究现状 (4)1.3 本文的工作 (4)第2章站内搜索引擎相关技术介绍 (6)2.1 全文检索技术 (6)2.2 .NET相关技术 (7)2.2.1 .NET平台 (7)2.2.2 Visual Studio2012开发平台 (7)2.3 介绍 (8)第3章站内搜索引擎的设计与实现 (9)3.1 站内搜索引擎功能需求 (9)3.2 站内搜索引擎总体设计及数据库设计 (10)第4章站内搜索引擎关键代码实现 (11)4.1 主界面 (11)第5章总结与展望 (14)参考文献 (15)摘要淘宝的出现，电子商务井喷式的发展，以及越来越多的社交网站、团购网站、专门类信息网站的出现，海量的数据蕴含在网站之内。

巨大的信息量无疑是把双刃剑，在给用户提供丰富信息的同时，也给用户提了一个大大的难题，如何在这海量信息中找到用户想得到的信息，尤其是当用户提供的是一组信息不是十分明确的词组时，如何能讲有用的信息条理清晰地提供给用户，这进一步刺激了站内搜索技术的发展。

本文在总结站内搜索功能的同时，在研究了站内搜索相关技术的基础上，设计并实现了一个简易的站内搜索引擎，实现了在内搜索的主要功能。

关键词：站内搜索；.NET；ABSTRACTThe Taobao emergence of e-commerce development spurt, as well as a growing number of social networking sites, group buying sites, the emergence of specialized class information website contains vast amounts of data within the website. A huge amount of information is undoubtedly double-edged sword, giving users a wealth of information, but also to provide the user a big problem, how to find a user wants information in this mass of information, especially when the user is offered a when information is not very clear set of phrases, how can speak clarity of useful information available to users, which further stimulated the development of the station search technology.This paper summarizes the station search function at the same time, in the study of the station search related technologies, based on the design and implementation of a simple site search engine, including the realization of the main functions of the search.Key words: Site Search; .NET; 第1章绪论自从有了计算机以后，人类开始用计算机保存信息，有保存就需要查找，于是出现了检索技术。

全文搜索引擎的设计与实现【摘要】随着互联网的出现和伴随着它的高速发展，人们获得信息的方式也越来越依靠网络的存在，但是随着网络资源的不断丰富，人们搜索一个信息的难度也在增加，搜索引擎就是在这种情况下发展而来，本文在分析了搜索引擎的研究现状的基础上，对传统分词算法加以改进，在一定程度上提高搜索的精确率和识别率。

【关键词】全文搜索；搜索引擎；分词随着互联网资源的飞速增长，搜索引擎的发展在很大程度上决定了互联网资源的使用率，只有不断增强搜索引擎的技术才能使我们更好的利用网络资源。

互联网的使用率也代表着一个国家网络的使用水平，而搜索引擎在很大程度就制约着网络资源的利用。

现在的搜索引擎技术还存在着很多的问题，需要我们不断的去改进。

目前的搜索引擎尚有很多的缺陷，主要体现在，网络资源的质量控制不足，由于缺乏一个系统的控制，所以资源的完整性和可靠性都不能得到保证，导致搜索引擎的无效搜索。

其次就是搜索引擎占用着太多的资源，由于采用的是链接是把资源站的信息传回本地，无疑会使网络的流量增加传输的困难，使网络限于瘫痪。

再次即使是做好的搜索引擎也不能做到对全网的一个覆盖，而且各搜索引擎没有明确的分工，重复搜索，造成资源的浪费，没有专门性的搜索引擎，大家都在做全面的搜索引擎，多而不精。

同时因为搜索引擎的技术发展还不是很完善，对于一些信息的检测会出现漏检，不能明确的标记要搜索的对象。

各搜索引擎也不能实现交叉覆盖。

需要用不同的搜索引擎检测才行。

搜索引擎技术是由信息检索技术发展而来的。

作为一种计算机本身的技术在网络上的使用，搜索引擎所要搜索的就是网页的集合，所以要做好一个搜索引擎也是相当困难和需要技术的，首先因为数据的分布是分散的，没有系统的整理，只是凌乱的存储在服务器上，对网络和平台的需求特别高，其次就是，网络信息的更新是飞速的，需要我们不断的去刷新数据，对技术的依托就更为强烈。

再次就是数据并不是只有一种结构，而是各种结构存在在网络上，形式不同，就需要有能处理不同形式的处理器，所以一个好的搜索引擎必须具备高效的性能和大量的内存和处理不同数据类型的能力。

江汉大学毕业论文（设计）文献综述综述名称全文搜索引擎的设计与实现姓名cccc学号2007082021372013年4月8日一、绪论目前定制和维护搜索引擎的需求越来越大，对于处理庞大的网络数据，如何有效的去存储它并访问到我们需要的信息，变得尤为重要。

Web搜索引擎能有很好的帮助我们解决这一问题。

本文阐述了一个全文搜索引擎的原理及其设计和实现过程。

该系统采用B/S 模式的Java Web平台架构实现，采用Nutch相关框架，包括Nutch，Solr，Hadoop,以及Nutch的基础框架Lucene对全网信息的采集和检索。

文中阐述了Nutch相关框架的背景，基础原理和应用。

Nutch相关框架的出现，使得在java平台上构建个性化搜索引擎成为一件简单又可靠的事情。

Nutch 致力于让每个人能很容易, 同时花费很少就可以配置世界一流的Web搜索引擎。

目前国内有很多大公司，比如百度、雅虎，都在使用Nutch相关框架。

由于Nutch是开源的，阅读其源代码，可以让我们对搜索引擎实现有更加深刻的感受，并且能够更加深度的定制需要的搜索引擎实现细节。

本文首先介绍了课题研究背景，然后对系统涉及到的理论知识，框架的相关理论做了详细说明，最后按照软件工程的开发方法逐步实现系统功能。

二、文献研究2.1 Nutch技术Nutch 是一个开源Java 实现的搜索引擎。

它提供了我们运行的搜索引擎所需的全部工具。

包括全文搜索和Web爬虫。

尽管Web搜索是漫游Internet的基本要求, 但是现有web搜索引擎的数目却在下降。

并且这很有可能进一步演变成为一个公司垄断了几乎所有的web搜索为其谋取商业利益.这显然不利于广大Internet用户。

Nutch为我们提供了这样一个不同的选择. 相对于那些商用的搜索引擎, Nutch作为开放源代码搜索引擎将会更加透明, 从而更值得大家信赖. 现在所有主要的搜索引擎都采用私有的排序算法, 而不会解释为什么一个网页会排在一个特定的位置。

全文搜索引擎的设计与实现前言面对海量的数字化信息，搜索引擎技术帮助我们在其中发现有价值的信息与资源。

我们可以通过google、百度这样的搜索引擎服务提供商帮助我们在Internet上搜索我们需要的信息。

但是在一些没有或不便于连入Internet的内部网络或者是拥有海量数据存储的主机，想要通过搜索来发现有价值的信息和资源却不太容易。

所以开发一个小型全文搜索引擎，实现以上两种情况下的信息高效检索是十分有必要的。

本设计着眼于全文搜索引擎的设计与实现，利用Java ee结合Struts,Spring,Hibernates以及Ajax等框架技术，实现基于apache软件基金会开源搜索引擎框架Lucene下的一个全文搜索引擎。

正文搜索引擎技术起源1990年，蒙特利尔大学学生Alan Emtage、Peter Deutsch和Bill Wheelan出于个人兴趣，发明了用于检索、查询分布在各个FTP主机中的文件Archie，当时他们的目的仅仅是为了在查询文件时的方便，他们未曾预料到他们的这一创造会成就日后互联网最的广阔市场，他们发明的小程序将进化成网络时代不可或缺的工具——搜索引擎。

1991年，在美国CERFnet、PSInet及Alternet网络组成了CIEA （商用Internet协会）宣布用户可以把它们的Internet子网用于商业用途，开始了Internet商业化的序幕。

商业化意味着互联网技术不再为科研和军事领域独享，商业化意味着有更多人可以接触互联网，商业化更意味着潜在的市场和巨大的商机。

1994年，Michael Mauldin推出了最早的现代意义上的搜索引擎Lycos，互联网进入了搜索技术的应用和搜索引擎快速发展时期。

以上是国际互联网和搜索引擎发展历史上的几个重要日子。

互联网从出现至今不过15年左右时间，搜索引擎商业化运作也就10年左右。

就在这短短的10年时间里，互联网发生了翻天覆地的变化，呈爆炸性增长。

---------------------------------------------------------------最新资料推荐------------------------------------------------------搜索引擎设计(精品)搜索引擎设计学号：姓名：专业：搜索引擎设计1. 研究思路当前主流的搜索引擎使用全文检索技术，收集因特网上几千万到几亿个网页，并对网页中的每一个词进行索引。

当用户查找某个关键词的时候，所有在页面内容中包含了该关键词的网页都将作为搜索结果被提交出来，在经过复杂的算法排序后展现给用户。

这种基于网页的全文检索系统能够适应大信息量查询的需要，具有很强的实用性。

模拟百度、 Google 等搜索引擎的运行模式，对此类搜索引擎的结构组成、关键算法、技术改进目标进行探讨。

2. 搜索引擎的构成一个搜索引擎由搜索器(Spider) 、索引器（Indexer）、检索器（Sercher）和用户接口(UI) 等四个部分组成。

系统首先由 Spider 即自动的收集程序收集网页的内容；然后由Indexer 将收集回来的内容进行分析，建立一个索引；再由Sercher 响应用户的检索请示，用户输入关键字后，搜索器要用这个检索词与建立的索引器匹配，匹配后作相关性排序；最后通过 UI1/ 8将排序结果送给用户。

系统结构如图 1 所示图 1 搜索引擎系统结构互联网数据库文件搜索器FullText文件索引器用户输入用户接口检索器Index文件2. 1 搜索器搜索器俗称蜘蛛，其功能是日夜不停地在互联网中漫游，耙回信息。

它要尽可能多、尽可能快地搜集各种类型的新信息，还要定期更新已经搜集过的旧信息，以避免死链。

目前有两种搜集信息的策略：(1) 从一个起始 URL 集合开始，顺着这些 URL 中的超链( Hyper link) ，以宽度优先、深度优先或启发式方式循环地在互联网中发现信息。

全文搜索引擎的设计与实现作者声明本人郑重声明：所呈交的学位论文是本人在导师的指导下独立进行研究所取得的研究成果。

除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。

本人完全了解有关保障、使用学位论文的规定，同意学校保留并向有关学位论文管理机构送交论文的复印件和电子版。

同意省级优秀学位论文评选机构将本学位论文通过影印、缩印、扫描等方式进行保存、摘编或汇编；同意本论文被编入有关数据库进行检索和查阅。

本学位论文内容不涉及国家机密。

论文题目：全文搜索引擎的设计与实现作者单位：江汉大学数学与计算机科学学院作者签名：XXX2013年5 月20 日学士学位论文论文题目全文搜索引擎的设计与实现（英文）Full-text search engine design andImplementation学院数学与计算机科学学院专业计算机科学与技术班级B09082021姓名XXX学号200708202137指导老师YYY2013 年5月20日摘要目前定制和维护搜索引擎的需求越来越大，对于处理庞大的网络数据，如何有效的去存储它并访问到我们需要的信息，变得尤为重要。

Web搜索引擎能有很好的帮助我们解决这一问题。

本文阐述了一个全文搜索引擎的原理及其设计和实现过程。

该系统采用B/S模式的Java Web平台架构实现，采用Nutch相关框架，包括Nutch，Solr，Hadoop,以及Nutch的基础框架Lucene对全网信息的采集和检索。

文中阐述了Nutch相关框架的背景，基础原理和应用。

Nutch相关框架的出现，使得在java平台上构建个性化搜索引擎成为一件简单又可靠的事情。

Nutch 致力于让每个人能很容易, 同时花费很少就可以配置世界一流的Web搜索引擎。

目前国内有很多大公司，比如百度、雅虎，都在使用Nutch相关框架。

由于Nutch是开源的，阅读其源代码，可以让我们对搜索引擎实现有更加深刻的感受，并且能够更加深度的定制需要的搜索引擎实现细节。

智能搜索引擎的设计与实现在当今信息爆炸的时代，搜索引擎成为了人们获取信息的重要工具。

智能搜索引擎的出现，更是极大地提高了信息检索的效率和准确性，为用户带来了更加便捷和个性化的服务。

那么，智能搜索引擎是如何设计与实现的呢？要理解智能搜索引擎的设计与实现，首先得清楚搜索引擎的基本工作原理。

搜索引擎就像是一个巨大的信息库管理员，它的任务是在海量的数据中快速准确地找到用户所需的信息。

当用户输入关键词进行搜索时，搜索引擎会在其索引库中进行查找匹配，并按照一定的算法对搜索结果进行排序，然后将相关的网页或文档展示给用户。

智能搜索引擎在这个基础上有了很大的改进和提升。

它不仅仅是简单的关键词匹配，还能理解用户的意图，提供更加精准和有用的结果。

为了实现这一点，智能搜索引擎需要具备自然语言处理的能力。

自然语言处理是智能搜索引擎的核心技术之一。

它使得搜索引擎能够理解用户输入的自然语言文本，而不是仅仅局限于关键词。

通过对语法、语义和语用的分析，搜索引擎能够更准确地把握用户的需求。

例如，当用户输入“我想吃川菜”时，智能搜索引擎不仅能理解“川菜”这个关键词，还能明白用户的意图是寻找关于川菜的餐厅或菜谱等信息。

在设计智能搜索引擎时，数据的收集和预处理也是至关重要的环节。

搜索引擎需要从互联网上抓取大量的网页和文档，并对这些数据进行清洗、分类和标注。

数据的质量和多样性直接影响着搜索结果的准确性和全面性。

同时，为了提高搜索效率，还需要对数据进行索引构建，以便在搜索时能够快速定位和检索。

搜索算法的设计是智能搜索引擎的关键。

常见的搜索算法包括布尔模型、向量空间模型和概率模型等。

这些算法通过对文本的特征提取和相似度计算，来确定搜索结果的相关性和排序。

此外，基于机器学习的算法也被广泛应用于智能搜索引擎中，如决策树、支持向量机和神经网络等。

这些算法能够根据用户的行为数据和反馈不断优化搜索结果，提高搜索引擎的性能。

个性化推荐是智能搜索引擎的另一个重要特点。

毕业论文（设计）论文（设计）题目：站内全文搜索引擎的设计与实现目录摘要......................................................................... 错误!未指定书签。

..................................................................................... 错误!未指定书签。

第1章绪论 .............................................................. 错误!未指定书签。

1.1 课题的研究背景与意义 ............................... 错误!未指定书签。

1.2 研究现状 ....................................................... 错误!未指定书签。

1.3 本文的工作 ................................................... 错误!未指定书签。

第2章站内搜索引擎相关技术介绍 ...................... 错误!未指定书签。

2.1 全文检索技术 ............................................... 错误!未指定书签。

2.2 相关技术 ....................................................... 错误!未指定书签。

2.2.1 平台 ...................................................... 错误!未指定书签。

2.2.2 2012开发平台 ................................... 错误!未指定书签。

毕业论文（设计) 论文(设计）题目:站内全文搜索引擎的设计与实现目录摘要 0ABSTRACT (1)第1章绪论 (2)1。

1 课题的研究背景与意义 (2)1.2 研究现状 (3)1。

3 本文的工作 (3)第2章站内搜索引擎相关技术介绍 (5)2.1 全文检索技术 (5)2。

2 .NET相关技术 (6)2.2.1 。

NET平台 (6)2.2。

2 Visual Studio2012开发平台 (6)2。

3 介绍 (7)第3章站内搜索引擎的设计与实现 (8)3。

1 站内搜索引擎功能需求 (8)3.2 站内搜索引擎总体设计及数据库设计 (9)第4章站内搜索引擎关键代码实现 (10)4.1 主界面 (10)第5章总结与展望 (13)参考文献 (14)摘要淘宝的出现,电子商务井喷式的发展,以及越来越多的社交网站、团购网站、专门类信息网站的出现，海量的数据蕴含在网站之内。

巨大的信息量无疑是把双刃剑,在给用户提供丰富信息的同时，也给用户提了一个大大的难题,如何在这海量信息中找到用户想得到的信息，尤其是当用户提供的是一组信息不是十分明确的词组时，如何能讲有用的信息条理清晰地提供给用户,这进一步刺激了站内搜索技术的发展。

本文在总结站内搜索功能的同时，在研究了站内搜索相关技术的基础上,设计并实现了一个简易的站内搜索引擎，实现了在内搜索的主要功能。

关键词：站内搜索;.NET;ABSTRACTThe Taobao emergence of e—commerce development spurt, as well as a growing number of social networking sites, group buying sites，the emergence of specialized class information website contains vast amounts of data within the website. A huge amount of information is undoubtedly double-edged sword, giving users a wealth of information, but also to provide the user a big problem，how to find a user wants information in this mass of information，especially when the user is offered a when information is not very clear set of phrases，how can speak clarity of useful information available to users，which further stimulated the development of the station search technology.This paper summarizes the station search function at the same time，in the study of the station search related technologies，based on the design and implementation of a simple site search engine, including the realization of the main functions of the search.Key words: Site Search; 。